The Architecture Problem That's Breaking AIs for Content Management (and the Secret Sauce to Fix It)

The Martin-Gropius-Bau sticks out in my commute to Adobe's Berlin office: a russet neo-Renaissance masterpiece from 1881. Martin built it after the Paris Commune, when Berlin thought good architecture could prevent revolutions, every frieze an argument for order.

Martin lived long enough to see the world that necessitated his buildings disappear – train stations becoming glass cathedrals, factories replacing cathedrals. His great-nephew Walter carried these contradictions to America's highways and open-plan offices, where he claimed what Martin couldn't: that beauty might live in absence rather than abundance.

This morning I'm thinking about how every CMS conversation sounds like that family argument. Traditional systems inherit Martin's ambition: more layers, more structure, more ways to express intention. These systems made perfect sense for their moment—until language models arrived, and the question became not what we can build, but what we should when our architect is silicon rather than stone.

Martin's building still stands because it solved a problem that disappeared while he was working on it. Tom Cranstoun's new approach doesn't solve disappearing problems—it solves the one in front of us now: how to build when our partners think in probabilities rather than columns.

Why AI Gets Stuck on Old CMS Architecture

Yesterday in our internal Slack, Bruce (one of your AI engineers) and I unpacked a question that keeps coming up: why do LLMs struggle with traditional CMS architectures?

Here's the problem: traditional CMS gives developers tremendous flexibility with deep nesting, recursive fragments, and complex component trees. But when you're teaching an AI with limited context windows, that flexibility becomes debilitating.

Traditional systems use primitives like "file" and "folder" with no inherent semantics. Edge Delivery uses native HTML semantics - the same language AIs already understand from billions of web pages.

Worse, traditional CMS encourages deep nesting and recursive structures. Great for developers, brutal for AIs trying to reason about content without long-term memory.

Then there's transparency. With traditional systems, you're debugging server-generated HTML you can't see behind bundled dependencies. With Edge Delivery, open DevTools and everything's right there - unminified, unobfuscated, fully transparent.

The final killer? Development loop speed. Traditional setups take minutes to see changes. Edge Delivery updates in the blink of an eye. For AI agents that need frequent iteration to bridge the gap between an 80% solution and the 99% you'll actually deploy, this speed isn't just convenient - it's essential.

Enter Tom's Framework

Tom's been living this problem every day. What started as a simple observation - that developing complex components in Edge Delivery meant jumping between Google Sheets, GitHub, and a local dev server - turned into something bigger.

His framework, documented in The Edge Delivery Services Developer Dilemma and How One Framework Solved It, does three things that made me stop and say "well, that's brilliant":

  1. Local-first development - no more context-switching hell
  2. AI-native architecture - gives your favorite coding assistant full visibility into code, content, and data
  3. Preserves what makes Edge Delivery fast - you still get those 100/100 Lighthouse scores

The architecture that AI dreams of (not the architecture that AI hallucinates of)

Remember what makes Edge Delivery special architecturally? We use HTML semantics natively, keep structures flat and simple, and make everything transparent and open source. Tom's framework doubles down on these principles.

Instead of fighting the platform to get sophisticated components, his dual-directory structure lets you:

Ready to See What's Possible?

For me, Tom's blog isn't just another technical post - it's a blueprint for pushing Edge Delivery further than most people thought possible.

The repository is live at on GitHub, and I can guarantee this: your next Edge Delivery project will be easier because of what Tom figured out here.

Check it out, drop thoughts in our Discord, and maybe we get Tom to join our next call to walk through it live.