Tag: tech strategy

Categories
AI Anthropic Apple Google OpenAI Spacexai

It’s the Harness, Stupid!

I’ve been wondering whether we’ve been looking at the AI stack from the wrong end.

Recently Kris Patel on X laid out a set of excellent questions that he’s looking to have answered as Anthropic and OpenAI move toward going public:

  1. Do you really need frontier-scale intelligence for every task?
  2. Can open-weight models provide an effective alternative to frontier models at a significant discount?
  3. Is the ultimate moat the intelligence or the harness?
  4. What other business models will the frontier labs have to adopt to make the unit economics work long term?
  5. How are you going to prevent distillation from capturing your IP and releasing it?

I’m going to explore only the third question here — moat versus harness. The other four deserve their own consideration, particularly once we have the Anthropic and OpenAI S-1s in hand, revealing for the first time the unit economics of the two largest frontier labs and how much runway they have to support the capacity they’ve contracted.

By “harness” we mean everything surrounding the model: the interface, context, memory, tools, orchestration, evaluation, permissions, and increasingly the user’s accumulated habits and data. The model supplies intelligence. The harness turns intelligence into a product.

Listening to Gavin Baker on the recent All-In episode sharpened this line of thought into something more concrete. He referenced a thought experiment from Eric Vishria: even if OpenAI or Anthropic lost their edge at the pure model layer, they would still retain significant value because of the product harness—the interface, the surrounding tooling, the orchestration—and the user familiarity and habits that have already formed around those platforms. Baker said there is a strong element of truth to it. I think he’s right, and the reasoning behind it is worth spelling out. A model can be replicated, distilled, open-weighted, or commoditized. A mature harness has network effects, switching costs, proprietary context, distribution, workflow integration, and accumulated user behavior. That’s a much harder thing to dislodge.

We are watching intelligence become more abundant and more interchangeable at the same time that the systems built around that intelligence are becoming stickier. On the developer side, the strongest examples are already clear. Cursor turns the IDE into a multi-model agentic environment with deep codebase awareness. Claude Code runs long-horizon coding agents from the terminal, planning, editing, testing, and iterating. Grok Build, Claude Cowork and similar tools emphasize parallel agents and tighter control over local context. In each case the model is a component; the surrounding system does the real work of routing, memory, tool use, and evaluation.

The consumer version of the same idea is now taking clearer shape at Apple. The rebuilt Siri AI shown at WWDC 2026 is not trying to win the pure model race. It is built as a personal harness. A system orchestrator decides what stays on-device with Apple’s Foundation Models, what moves to Private Cloud Compute, and when heavier reasoning is required. Personal context—messages, email, photos, calendar, notes, on-screen awareness—is handled largely on-device through the Spotlight semantic index and App Toolbox. Apple is designing the system so that personal context can be used without giving Apple itself access to it. Conversation history lives in a dedicated Siri app for the user to revisit. And it all syncs across all your Apple devices.

Here is the part I think matters most, and it’s easy to miss if you only read the privacy story. Apple’s Foundation Models framework doesn’t just call Apple’s own models—it’s built to support cloud models from other providers, including Claude and Gemini, conforming to a common protocol. Which means the system orchestrator, not the user, decides which model handles which task. This request goes to the on-device model. That one goes to Private Cloud Compute. A harder one might go to Claude or Gemini. The user doesn’t need to choose, and increasingly doesn’t need to know.

That’s the inversion worth exploring further. The frontier model stops being the interface and becomes a component underneath someone else’s interface. The harness chooses the intelligence. And the company that owns the harness—the OS, the identity layer, the permissions, the apps, the sensors, the notifications, the semantic index tying all of it together—has a form of leverage that has very little to do with whose model is smartest this quarter.

That reframes the subscription question too. I don’t think the right question is whether Siri gets good enough to beat ChatGPT or Claude at reasoning. I think Siri doesn’t need to win that fight at all. It needs to win a different layer entirely—the ambient assistant layer, not the reasoning layer. They’re doing different tasks. ChatGPT or Claude might remain where you go when you think, when I need to reason about something. Siri becomes where I go when I need something done: find (or make) my reservation, text my friend, find that old photograph, update my shopping list, schedule that meeting, add this thought to my notes, figure out when we’re free next week, remind me about that thing we discussed three months ago. Apple’s advantage as an ambient assistant isn’t primarily that it has your personal data. It’s that it has OS-level authority over the world that my personal data lives in.

Of course this is still early. Execution will determine how much of the architectural promise becomes daily reality. Reliability, agentic follow-through, and the quality of the on-device models will matter as much as the privacy story or the multi-model routing. But the strategic bet itself is clear, and it aligns with the broader shift: durable value is migrating toward the systems built around the models, especially systems that sit atop private, permissioned, personal context that competitors cannot easily reach. My early personal experience with the new Siri in iOS 27 betas has impressed me so far. All of this also seems to apply to Google in the context of their Pixel family of devices.

This doesn’t mean frontier labs lose. Pricing power still exists at the high end for the hardest agentic and long-horizon work. Open-weight models will continue to pressure costs and expand access. Distillation remains a real risk. But the more the capability gap narrows, and the more a harness like Apple’s can route among interchangeable frontier models rather than depend on any single one, the stronger the case that value settles into whoever controls the context—not whoever trained the model.

The coming Anthropic and OpenAI S-1s will tell us whether the frontier labs can make their economics of intelligence work. The next generation of Siri, Gemini, ChatGPT, Claude, and whatever comes after them may tell us something even more important: who gets to own the primary relationship with the user.

The model may be the engine. But the harness is where the driver sits.

What a time to be alive!

Categories
AI AI: Large Language Models Apple

The Slipstream Strategy

Apple had a problem no amount of money could solve. An iPhone can’t draw the power or shed the heat of a data center, so ten different tasks can’t mean ten different models fighting for the same sliver of RAM. Apple’s answer was to freeze one small, efficient base model into the device and then swap tiny adapters in and out of it in milliseconds — a summarization adapter for your texts, a Siri adapter for on-screen actions, and a handoff to Private Cloud Compute for anything heavier. The phone behaves like it’s running many models. It’s running one model wearing many hats.

That architecture — a frozen base plus swappable adapters — is quietly becoming the default way serious AI companies build, and it’s worth understanding why, because it inverts the assumption most people still carry into this industry.

The assumption is that winning means owning a frontier model. Sierra co-founder Clay Bavor pushed back on that on a recent 20VC episode: pouring capital into your own pre-training, he argued, tends to leave you holding a highly perishable bag of floating-point numbers. Open-weight models improve fast enough that yesterday’s frontier is next quarter’s commodity. The companies playing this well aren’t racing to out-spend the labs. They’re slipstreaming behind them — taking the free, state-of-the-art engine and putting all their effort into what sits on top of it.

What sits on top is LoRA — low-rank adaptation. The old failure mode was catastrophic forgetting: fine-tune a model hard enough on your own data and it forgets how to reason generally. LoRA sidesteps this by leaving the base model untouched and training a small set of additional parameters alongside it — a thin layer of expertise bolted onto a frozen foundation. You get real domain depth without touching the thing that makes the model work at all.

The business logic that follows from this is the actual point, and it’s simpler than it looks:

You stop being hostage to any one model provider — if a better open-weight model ships next month, you port your adapter, not your whole product. You can serve hundreds of differently-customized clients off one base model on one piece of hardware, instead of running a separate giant model per customer. You can ship a fix in an afternoon, because an adapter is a few hundred megabytes, not a training run. And in regulated industries, your proprietary data can train an adapter that never leaves your own infrastructure.

None of this is really a story about model architecture. It’s a story about where the moat moved. For a while the moat was raw capability — whoever had the best model won. Apple and Sierra are betting the moat is now somewhere else entirely: in how tightly you can weave a commodity intelligence into a specific workflow, a specific dataset, a specific customer relationship. The engine is free. The adapter is the business.

Categories
Business History IBM Infrastructure Nvidia Programming Semiconductors

The Half-Life of Moats

Prompted by an article on X by @magicsilicon on the CUDA moat. Research and drafting assistance from my AI intern assistant Clark.

The NVIDIA H100 looks, in retrospect, like an inevitability. It wasn’t.

What Jensen Huang built is more accurately understood as a sixteen-year accumulation of optionality — a platform investment made in 2006 for a market that wouldn’t fully materialize until 2022. NVIDIA intros the G80 architecture in November 2006, laying the groundwork for CUDA’s release a few months later. The stated ambition was to let scientists write C++ that ran on GPU cores without needing to understand 3D graphics pipelines. The unstated bet was that parallel computation would eventually matter for something bigger than rendering shadows in video games.

For sixteen years, it mostly didn’t. Not at scale. Not commercially. CUDA lived in research labs and HPC clusters. It attracted a small, devoted, and economically marginal user base — the kind that papers cite but investors ignore. NVIDIA kept investing in it anyway: cuDNN for deep learning operations, cuBLAS for linear algebra, a layered ecosystem of libraries that made CUDA not just accessible but nearly irreplaceable for anyone doing serious numerical computation. When TensorFlow and PyTorch emerged as the standard frameworks for neural network research, they didn’t adopt CUDA because it was the only option. They adopted it because CUDA was where the optimized kernels already lived.

AlexNet won the ImageNet competition in 2012 and did it on two NVIDIA GPUs. The deep learning community noticed immediately. The financial community largely did not.

Then ChatGPT launched in November 2022, and suddenly everyone needed H100s they couldn’t get.

The parallel to Intel is instructive and also undersells how strange this kind of story looks while you’re living through it. Intel was founded in 1968 as a memory company. DRAM. The founders — Noyce, Moore, Grove — were materials scientists and engineers who believed the future was in silicon memory chips. They were right, briefly: in the early 1970s Intel dominated the DRAM market. By 1984, that share had collapsed to 1.3%, ceded almost entirely to Japanese manufacturers who had commoditized the product.

What saved Intel wasn’t a pivot so much as a realization that a stopgap had become a foundation. The 8086, conceived in 1976 as an internal hedge and launched in 1978 was never supposed to matter. It was a 16-bit processor designed to hold off Zilog while Intel finished its ambitious 32-bit iAPX 432 architecture. The 8086 was assigned to a single engineer. “If management had any inkling that this architecture would live on through many generations,” its designer Stephen Morse later recalled, “they never would have trusted this task to a single person.”

IBM chose the 8088 — a cost-reduced variant — for the original IBM PC in 1981. That decision wasn’t destiny, it was simply a procurement. And yet from that accident of selection, Intel’s x86 line became the backbone of personal computing for four decades. The Pentium in 1993 was Intel’s Wintel moment — the flag bearer the @magicsilicon tweet gestures at — but the flag had been quietly sewn since 1978.

What these histories share is not just a pattern of “slow build, explosive payoff.” The structural similarity is subtler: in both cases, the moat was a software abstraction layer built on top of hardware. Intel’s real lock-in wasn’t transistor count or clock speed. It was backward compatibility — the commitment, formalized with the 80386 in 1985, that every future Intel chip would run software written for older ones. That promise created a flywheel that trapped developers and buyers in a virtuous (for Intel) dependency loop for decades.

CUDA is the same architecture at a different layer. The lock-in isn’t the H100’s 80 gigabytes of HBM3. It’s that switching to an AMD MI300X or Google TPU means potentially rewriting training pipelines that have been optimized against CUDA kernels for years. AMD’s ROCm platform exists. It is, by most accounts, maturing. Engineers who have tried the migration report that it costs months and hundreds of thousands of dollars. The moat isn’t a wall. It’s accumulated friction — the switching cost of a decade of engineering decisions baked into codebases that no one wants to touch.

But to find the actual origin of this pattern, you have to go back further than Intel. To 1964, and to a decision IBM made that Fred Brooks — its project manager — called a bet-the-business move.

The IBM System/360 was announced on April 7, 1964, after five years of turbulent internal development. What it introduced wasn’t just a new computer. It was a new concept: the separation of architecture from implementation. Before the 360, IBM ran five incompatible product lines simultaneously. A customer who outgrew their machine had to scrap all existing software and start over. The 360 replaced all five lines with a single unified architecture — six models covering a fiftyfold performance range, all running the same operating system, all sharing the same instruction set. The name itself encoded the ambition: 360 degrees, all directions, all users.

Gene Amdahl, the 360’s chief architect, had a precise formulation for what this meant: the architecture was “an interface for which software is written, independent of any implementation.” The Principles of Operation manual described what the machine did; separate Functional Characteristics documents described how each model did it. This distinction — separating the contract from the execution — was genuinely new. It’s the conceptual root of everything that came after.

The 360 generated over $100 billion in revenue for IBM and established the first platform business model in computing. Jim Collins would later rank it alongside the Model T and the Boeing 707 as one of the three greatest business achievements of the twentieth century. But its deepest legacy was architectural: the insight that if you make your abstraction layer the standard, the hardware underneath becomes fungible. Customers didn’t buy specific IBM machines. They bought into OS/360. The machines were an implementation detail.

Intel understood this by the 1980s, even if implicitly. The 80386’s backward compatibility commitment in 1985 was IBM’s 360 insight applied to microprocessors — the architecture is the product, the silicon is the vehicle. CUDA is the same insight applied to GPU compute. What NVIDIA sold researchers in 2006 wasn’t the G80 card. It was the abstraction: write parallel code in C++, run it on any NVIDIA hardware, trust that the next generation will be faster and compatible.

The pattern is now sixty years old. It has reproduced in every major platform transition. And it keeps working for the same reason it worked in 1964: when you own the layer that developers write to, your customers’ switching costs compound every year they stay.

There’s something worth sitting with here. Neither Jensen Huang in 2006 nor Gordon Moore in 1968 could have specified exactly what the payoff would look like. What they shared was a willingness to build infrastructure for a demand they could sense but not yet see — and the discipline to keep investing in it through the long years when it looked like a research project rather than a business.

The question that doesn’t resolve cleanly is whether that kind of patience is a strategy or a personality. And whether, in an industry that now moves faster than the cycles it’s lived through, sixteen-year moats are still the kind that get built.

Which raises the uncomfortable corollary: the same AI tools that CUDA enabled may be what ultimately erodes it.

The attack on CUDA’s moat is now structurally different from anything AMD or Intel could mount before. OpenAI’s Triton compiler lets developers write GPU kernels in Python without touching CUDA at all, and generates optimized machine code that often matches hand-tuned CUDA performance. MLIR — Multi-Level Intermediate Representation, originally from Google — provides a compiler infrastructure that can target any hardware backend from a single codebase. AMD’s ROCm has historically been dismissed as immature; ROCm 7, released this year, delivers meaningfully better inference performance than its predecessors. And perhaps most directly: Claude Code reportedly ported a CUDA codebase to AMD’s ROCm in thirty minutes — work that previously took months of engineering time.

The irony is almost too neat. CUDA’s moat was built on accumulated switching costs: the friction of rewriting code, the library dependencies, the tribal knowledge encoded in a decade of kernel optimizations. AI coding tools are specifically good at exactly that kind of mechanical, high-context translation. The weapon is attacking the wall it was built behind.

That said, it’s worth being careful about the speed of this. Abstraction layers that “should” erode moats often take far longer than expected, because the moat isn’t just the code — it’s the ecosystem of tooling, documentation, community knowledge, and hardware-software co-optimization that took eighteen years to compound. Triton and MLIR are real. They’re also early. The question isn’t whether the moat is vulnerable; it’s whether it erodes before NVIDIA’s next generation of chips makes it irrelevant to argue about.

As for what comes next — which company is building the IBM 360 of this decade — the honest answer is that it’s too early to call with confidence. But there’s a candidate worth watching.

Anthropic’s Model Context Protocol, launched in late 2024, has the structural fingerprint of a platform play. MCP is a standard for how AI agents connect to external tools and data sources — a common interface layer, hardware-agnostic (or rather, model-agnostic), that any system can implement. By late 2025 it had been donated to the Linux Foundation, adopted by OpenAI and Google, and was tracking 97 million monthly SDK downloads. There are now over 10,000 MCP servers. It is becoming the way agents talk to the world.

The parallel to OS/360 is imprecise but instructive. What IBM built in 1964 was a standard interface between software and hardware that decoupled what you wrote from what you ran it on. MCP is attempting something similar one abstraction layer higher: decoupling what an agent does from the specific models, tools, and data sources it does it with. If it becomes the standard — the layer that developers write to — then whoever owns or most deeply shapes that standard controls the integration tax of an industry whose applications we can’t fully specify yet.

The counterargument is that open standards, once donated to foundations and broadly adopted, don’t generate the same lock-in as proprietary platforms. OS/360 was IBM’s. CUDA is NVIDIA’s. MCP is now the Linux Foundation’s, with OpenAI and Google as co-stewards. The historical pattern suggests the moat accrues to whoever owns the layer, not whoever invented it.

Which may mean the next great platform play is still being assembled in a room we haven’t seen yet — the way IBM’s System/360 was being architected in a Connecticut motor lodge in 1961, three years before anyone else knew what was coming.