We Built Web Frameworks for Humans. What if We Built for the Agent?

2026-07-25

Every popular frontend framework of the last decade solves the same underlying problem: a person can only hold so much in their head at once. State management, component reuse, routing conventions, build tooling — all of it exists because a human writing a large application by hand needs guardrails against their own working memory.

Carapace's content doesn't have that problem, because a human isn't writing it by hand. An LLM, working through MCP tool calls, is. And a model doesn't forget what a variable holds three files away, doesn't need a component system to avoid repeating itself, and doesn't get lost in a deeply nested router. The cognitive limits frameworks exist to work around were never the model's limits to begin with.

So we didn't bring one

Carapace's site is a small, hand-rolled TypeScript build script. It reads content, runs it through plain template functions, and writes static HTML to disk. No framework, no client-side JavaScript by default, no hydration step translating server output back into something interactive. The build is boring in the way a build should be boring — fast, predictable, and the same shape every time.

This isn't a rejection of frameworks in general. It's a recognition that the specific problems they solve mostly aren't the problems a content platform written by an agent actually has.

What we kept instead of framework abstractions is a small, enumerated vocabulary: a fixed set of HTML tags and attributes an agent is allowed to write, plus a handful of purpose-built layout primitives — a card, a row that wraps, a video embed — for the small number of things plain semantic HTML doesn't cover on its own. Growth happens by adding to that vocabulary deliberately, never by loosening what raw markup can already do.

The trade we're making

This isn't free. A framework's component model genuinely helps a large team of humans build a large, stateful application — that's a real, useful thing to have, and it's not what we're offering. Carapace is built for content that's shaped like a site: a blog, docs, marketing pages. If what you're building is closer to an interactive application than a publication, a framework is still the right tool.

What you get in exchange for giving that up: content an agent can write directly and safely, because there's no client-side execution path for it to accidentally — or maliciously — reach. A build that takes seconds because there's nothing to bundle. And a site that starts near the performance ceiling by default, not because someone remembered to optimize it, but because there was never anything slow to begin with.

We didn't build this because vanilla HTML is fashionable again. We built it because we sat down to build a CMS with no server, and a framework turned out to be the first piece of unnecessary infrastructure standing in the way.

If you want the fuller architecture — why there's no API layer either, not just no framework — start with the docs.