2nd of April 2026

TLDR: The admin panel is a façade. EmDash’s real product is an API designed for AI agents, not humans. The WordPress-like UI is just the adoption bridge. The interesting question, what interfaces humans actually want in an agentic world, remains unanswered.

Press enter or click to view image in full size

An em dash ( — ) is a typographic interruption. A break in the sentence. A moment where the writer steps back and inserts something the main clause couldn’t quite hold.

It’s a fitting name for a CMS that arrived on April 1st and immediately made me question whether the thing I was looking at — a familiar-looking blog backend — was actually the product at all.

What EmDash Is, On the Surface

EmDash launched this week as a Cloudflare project built on Astro. End-to-end TypeScript. SQLite locally, Cloudflare D1 in production. Images on disk or R2/S3. One-click deploy to Cloudflare Workers, Netlify, or Vercel.

I installed it locally the same evening. The setup is genuinely fast. Within twenty minutes, I had a running instance, a theme, and a handful of test posts. The admin interface looks like WordPress — deliberately so, according to the documentation. There’s even a porting guide for WordPress themes, complete with mapping tables from WordPress template tags to EmDash API calls.

It felt comfortable. Familiar. Almost suspiciously so.

That’s when I started reading the architecture decisions more carefully.

The Admin Panel Is Not the Product

Every architectural decision in EmDash points in the same direction: away from the human editor, toward the machine.

Content is stored as portable text — structured JSON, not HTML strings. Custom content types get their own database tables with typed fields. There’s an MCP server for direct CMS interaction. The CLI outputs JSON. The documentation is explicitly structured for machine consumption.

None of these decisions optimizes for the human sitting in front of a browser. They optimize for an AI agent that reads, writes, and reasons about content programmatically.

The WordPress-lookalike admin panel is the adoption strategy. The API is the product.

This isn’t a criticism, it’s a recognition of what EmDash is actually betting on: that within a few years, the primary “user” of a CMS will not be a human clicking through form fields, but an agent operating on structured data. The familiar interface lowers the barrier to adoption while that transition plays out. It’s a bridge architecture.

The Question EmDash Doesn’t Ask

Joost de Valk’s launch post frames this clearly: “Every CMS generation reflects the tools used to build with it. WordPress was shaped by FTP, PHP, and shared hosting. The next generation will be shaped by AI agents.”

That framing is probably right. But it skips a harder question: what do humans actually want from a CMS interface in a world where agents will do most of the building?

There are at least three plausible futures, and they lead to very different products:

Future A

The interface disappears. Humans set intent and policy. Agents create, edit, and publish. The admin panel becomes a configuration surface for agent behavior, not content. This is the logical endpoint of EmDash’s architecture.

Future B

The interface becomes a review layer. Humans exit the role of creation but retain oversight. The CMS becomes a different view: the agent proposes, the human approves. This maps well onto existing editorial workflows in larger organizations, just with the input/output ratio inverted. A backend remains relevant here, but radically redesigned: fewer form fields, more trust decisions.

Future C

The interface becomes a statement. As agent-generated content floods the web, a visible human authorship signal becomes a differentiator. Some creators will deliberately choose not to delegate. The interface becomes a craft tool for people who are making a point of staying in the loop.

EmDash’s current design assumes Future A is inevitable and builds toward it. The WordPress-like frontend is a transitional concession to the present. That’s a coherent bet. But it’s still a bet.

Where TYPO3 Sits in This Picture

I run an agency that specializes in TYPO3, and I’ve spent the past year thinking about how enterprise CMS platforms survive an agentic transition. EmDash is clarifying.

TYPO3’s multi-user editorial workflows, role-based access, approval chains, audit logs, and version control are more closely aligned with Future B than those of any other CMS I know. A city administration, a university, a regulated insurer: none of them will let an agent publish without human review. The question isn’t whether there will be an interface; it’s what that interface looks like when humans are reviewing rather than creating.

That’s a genuinely different design problem from the one EmDash is solving. And it’s one where TYPO3’s institutional complexity becomes an asset rather than a liability.

The gap TYPO3 has is the inverse of EmDash’s gap. EmDash has an agent-native architecture but an empty plugin ecosystem and only 2 months of production history. TYPO3 has deep enterprise workflow logic and a 25-year ecosystem, but hasn’t yet articulated itself as the governance layer for human-agent collaboration.

Both are incomplete answers to the same question.

What the Name Gets Right

An em dash interrupts a sentence to insert something the main clause couldn’t hold.

EmDash, the CMS, challenges the assumption that backend interfaces are primarily for humans and introduces a different premise: that agents are becoming the primary builders and that the CMS should be designed for them first.

Whether that premise plays out fully, partially, or not at all depends on which future actually arrives. But asking the question out loud, in architecture rather than just in marketing copy, is itself meaningful.

I’ll keep running it locally. And I’ll keep watching how the admin panel evolves, or whether it quietly fades into a configuration sidebar while the MCP server does the actual work.

That would be the most honest version of what EmDash is already implying.

Olivier Dobberkau is CEO of dkd Internet Service GmbH, a Frankfurt-based TYPO3 agency, and President of the TYPO3 Association. This post represents my own personal view and does not reflect any official statement.