A friend opened a recent message with this: "Erik, the world has WordPress, Strapi, Sanity, Payload, Ghost, Wagtail, Directus, Webflow, and 200 niche ones. Why?"
Fair. I have been sitting on that question for about a year, and I think I finally have an answer that is honest enough to publish. So here it is, with no marketing veneer on top.
1. I wanted a CMS where the API is the agent surface
Almost every CMS I have worked with treats AI as a plugin. You install a thing, it bolts a chat widget into the sidebar, it can summarize a post or maybe suggest tags, and that is the extent of it. The actual content model sits behind a REST or GraphQL layer that was designed in 2014 for a human clicking buttons, and the AI integration is a thin wrapper on top.
I wanted the opposite. I wanted the primary API surface and the agent surface to be the same surface. In Squilla, the CoreAPI is what every part of the system already speaks. Extensions use it, the admin UI uses it, and the MCP server exposes it directly to any agent that wants to talk to the CMS. There is no "AI mode" because there is no non-AI mode. The 100+ CoreAPI methods you would call from Go are the same 100+ tools an agent gets over MCP. One contract.
That is the bet I most want to be right about. If agents are going to be a normal part of how people build sites, then a CMS that was designed for agents from day one should feel obviously better than one that grew a chat panel.
2. Extensions should not be locked to one language
The other thing that bothered me is that most extension models in 2026 are still some flavor of PHP hooks or JavaScript-only. WordPress is PHP. Strapi and Payload are Node. Ghost is Node. Sanity is JavaScript end to end. If you want to write a CMS extension, the language is picked for you.
Squilla extensions are gRPC plugins. That sounds boring until you realize what it means in practice. An extension is a separate process the kernel talks to over gRPC, which means it can be written in any language that speaks gRPC. Go, Rust, Python, anything. The extension owns its own database tables, its own admin UI micro-frontend, its own HTTP routes, its own event subscriptions. It is closer to a Debian package than to a WordPress plugin.
I want someone to write a Rust extension that does image processing and never has to apologize for not being JavaScript. I want a Python ML extension that lives next to a Go SEO extension in the same install. The plumbing should not care.
3. Core stays small, and there is a hard rule for it
Most mature CMSes are giant. The core ships with media handling, email, SEO, comments, taxonomies, twenty kinds of caching, and a thousand hooks you will never use. Then every extension you add wires into that pile of built-in behavior, which means the core is impossible to evolve without breaking things.
Squilla has one rule about this, and I enforce it on myself every week. If removing a feature would leave dead code in core, that feature belongs in an extension. Image optimization? Extension. Email templates? Extension. The robots.txt file? Extension. The kernel is content nodes, rendering, auth, the CoreAPI, the event bus, and the extension loader. That is it.
This makes the core boring on purpose. Boring core means I can keep it fast, keep it stable, and keep it small enough that a single person can hold the whole thing in their head. The interesting work happens at the extension layer, which is exactly where I want it to happen.
4. I like Go and I do not want to live in Node forever
This is the least strategic reason and probably the most honest one. I have spent years migrating WordPress sites for clients. I have written more PHP than I would like to admit. I have shipped Node services. I respect both. I also do not want to spend the next decade in either of them.
Go is the language I am happiest writing. Single binary, great concurrency story, fast cold starts, boring deployment. Building Squilla in Go was partly a technical decision and partly me scratching an itch that has been growing for a long time. I am not going to pretend otherwise.
So is this the right bet?
Maybe not. It is entirely possible that the existing CMSes will graft on enough AI features that the gap closes, or that a different architecture wins, or that the whole "agent-first" framing turns out to be a phase.
But this is a clean bet. The pieces line up. The CoreAPI is the agent surface. The extension model does not pick your language for you. The core stays small because there is a rule that keeps it small. And the binary is one file.
It might be the wrong bet, but it is mine, and it is the one I want to be making in 2026. If you want to poke at it, the project lives at github.com/squilla/squilla. Issues and ideas are welcome. So is honest skepticism. 🦐