· Essay
Frontiers & Foundations
Everyone is racing to the frontier right now and just a few talk about the floor they're standing on.

"Everyone is racing to the frontier right now and just a few talk about the floor they're standing on."
Originally published as an X Article on Sep 22, 2026. Draft note: confirm: rights to the cover illustration
The geometry
There's a geometry I keep coming back to: Our foundation is a floor. The frontier is the ceiling you can reach by standing on it. You rarely get higher by jumping harder. You get higher by raising the floor, and when the floor rises, everything above it comes within reach. Foundation work doesn't compete with frontier work. It's what makes frontier work achievable. Very similar to James Clear's: "You do not rise to the level of your goals. You fall to the level of your systems."
Unencumbered vs. bolt-ons
That explains something that confuses a lot of people right now. The zero-to-one products landing every week (e.g. Grok Bot, Muse, Instinct) are not smarter than you. They're unencumbered. No foundation means no legacy tax, so they start at the frontier by default. That's not a moat. It's a starting position, and it's temporary, because they'll accumulate debt too.
The timeline is compressed. In under two years UX mental models went from multi-turn chat interfaces, to async cowork modalities, to sub-agent claws, to personified JTBD as bots, to a single bot governing multiple goals and artifacts from a single thread.
The frontier moves faster than anyone can bolt onto it.
Companies rush from A to B while the industry gallops to D, left to think about their next move. This is many times harder for the 15-20 year old platforms that are trying to race by bolting frontier AI onto a foundation that was never designed to hold it. It demos beautifully and collapses on contact with the real world because the architectures are incompatible and the experience mental models are alien to each other. See how every product's first-gen AI chat module repeated the main canvas content verbatim.
The Microsoft Ads case study
I have been leading this exact work at Microsoft Ads in the past year, where my team has rebuilt our foundation - 431 pages of UI moving real ad budgets, spread across two front-end stacks (Backbone and React) and four generations of design system: Fluent 1 and 2, plus two generations of our own Ads UI Kit built on top of Fluent. From the outside that reads as aesthetic inconsistency. From the inside it's a city that was built over decades renewing its power grid.
The moment you want the new and shiny agentic capability, fragmentation stops being cosmetic. You're trying to teach an agent to operate your product, and the product doesn't operate the same way twice. Same action, different pattern, different component, different code. An agent can't generalize across a system that contradicts itself. Hard to understand, hard to recall and hard to rebuild (if you want GenUI, and you do).
This is the design system moment. Brad Frost called it last December: agents consume a design system exactly as written, so the system has to become machine-readable infrastructure (Agentic design systems in 2026). Here's what that took on a twenty-year-old platform. We had to close these gaps by auditing, redesigning, componentizing and documenting a new agent-ready design system for engineering and agents to consume. It took a year, and part of that year went to making our Figma agent-readable.

Then we built an agent ("Frankie") that takes a component from Figma, builds it in code, runs the visual diff, and hands it off to Storybook and engineering.

We are 90% done migrating to the newest design system. This will enable agents to operate, recall and rebuild (GenUI) in a much more consistent and reliable way. It even made our own prototyping tools much more accurate in building with our production components.
All this to say the foundation work isn't a prerequisite to the frontier. It is the frontier work. The honest version is harder than the FOMO version. Fixing foundations is invisible, slow, and politically thankless while the industry sprints past you. It's the crawl in Zach Lloyd's crawl, walk, run for the software factory, and nobody gets to skip it. But the payoff isn't the redesign. It's that everything we want to build next is now actually buildable.
PS: the MCP objection
MCPs will make UIs redundant, or so the argument goes. @vimtor said not long ago:
I don't want AI in your app, I want your app in my AI
Build the MCP on your APIs and the agent never touches your screens, so who cares about four generations of design system?
Fair. Two caveats: First, it's early. MCP puts your product inside people's favorite LLM - this is the super-app model that never broke ground in the West, and MCP usage in LLMs hasn't reached mass market yet. Most people are still using LLMs as the new Google, so for years (or months, who knows) to come, humans will still be in the UI, checking what the agent did, rather than juggling status across multiple chat threads inside an LLM. Second, an MCP only routes around the UI debt if the API underneath is coherent, and in a twenty-year-old platform the API carries the same decades: partial coverage, uneven naming, and the gaps get filled by agents driving the UI directly. Either way the agent lands on your floor. The only question is which layer of it.
Raise the floor, the ceiling follows.