We Built Six CMSes Before Inkwell. Here's What Each One Taught Us.

#The Honest Part

There is a specific kind of engineering mistake that looks like progress. You need a piece, you build it, it works, you ship. The next project needs the piece again — but slightly different, and the old one is coupled to assumptions that don’t hold anymore — so you build it again. Three projects in, you have three CMSes. Six projects in, you have six.

This is the story of those six, and of the seventh one (Inkwell) that was only buildable because of them.

#The Six, in Order

#1. resident-cms — where agents and CMSes were the same organism

Built December 2025. Python monolith. Everything lived in one repo: the CMS that published to blog.shabrang.ca, the Telegram bot that talked to users, the River daemon that ran reflection loops every four hours, a reflection service, a multi-model failover client with a circuit breaker, a rate limiter, approval queues, a supervisor. Agents were folders: agents/river_consciousness/, agents/shabrang_bot/, agents/frc_agent/. The content engine and the agent were literally the same codebase.

The lesson it wrote into the code: coherence cannot be imported. When memory, tasks, agents, comms, and content all live inside each other through Python imports, every new feature creates a new circular dependency. The monolith became unmaintainable at about twenty top-level Markdown status files.

#2. cli / Mumega Sovereign OS — the monolith grew organs you could see

December 30, 2025 → April 4, 2026. 224 commits. This is where the monolith acquired agency. The River daemon ran dream → reflect → metabolism cycles. A Solana wallet module. Work-settlement, work-slashing, agent trust. A task MCP server. Ten Gemini API keys rotated on failure. Telegram as the primary human UI. The CMS side was still in there — under mumega/core/cms/ — but it was no longer the point. The point was the living system.

The final commit is named: “sovereign logic extracted, hive evolution, task MCP rewritten.” That commit is the moment the monolith agreed to die.

The lesson: one organism is good for proving an idea is possible. It is terrible for running that idea in production. Every subsystem eventually wants its own lifecycle, its own deployment cadence, its own failure mode. When they all share a process, you get one brittle thing instead of many robust ones.

#3. SOS — the extraction lands

January 11, 2026. Sovereign Operating System. Agents are no longer processes that SOS manages; they are external sessions (Claude Code, Cursor, Codex, the CLI as a thin gateway) that connect over MCP. SOS becomes the runtime — a bus, a squad service, a kernel, an economy. The city metaphor starts to show up in the data: a QNFT registry for citizens, wallet/settlement/slashing for economy, FMAAP-tiered governance.

But SOS still had content inside it — skills, memory, site-building bits. It was obvious that the content layer wanted to leave. So did memory. So did the customer-facing edge.

graph LR
A[resident-cmsmonolith] —> B[climonolith w/ organs]
B —> C[SOSruntime + bus]
C —> D[mirrormemory microkernel]
C —> E[inkwelledge layer]
C —> F[mumcpWordPress bridge]
D —> G[mumega.comsynthesis]
E —> G
F —> G

#4. mumcp / SitePilotAI — the “what if the CMS already exists” answer

Here is the fork in the road most people don’t think about when they “build a CMS”: there is already a CMS the world has agreed on, and it is WordPress. If you want AI agents to manage content at scale, and your customers are businesses that already have WordPress sites, the cheapest thing you can do is not build a new CMS. You build a bridge.

mumcp (originally SitePilotAI — the spai_ prefix on its API keys is still the fossil) is that bridge. A WordPress plugin that turns any site into an MCP server. 239 tools across 15 categories.

You install the plugin. You generate an API key. The agent calls wp_introspect() and gets the site briefing. Then it calls wp_build_page with a blueprint list (hero, features, pricing, faq, cta) and a page is built. wp_edit_widget does surgical edits. wp_get_widget_schema returns the correct control keys so the agent doesn’t silently break rendering by guessing.

The lesson: a CMS is not a destination; it’s a surface. If the customer’s reality is WordPress, meet them at WordPress. We did not stop building our own CMS — but we also stopped pretending ours was the only game. Build a bridge to the biggest one in the world, take those customers as they are.

#5. shabrang-cms — the one that shipped to real users

Next.js 15. 281 markdown files. 60+ React components. GitHub Discussions as the comments system (so moderation gets handled by GitHub’s infra). Cloudflare Workers AI for automated moderation on top of that. Four languages. This is the CMS that went to production at shabrang.ca and stayed there.

It is also the CMS that made it painfully obvious that every serious content site needs the same eight things:

Every one of the six earlier systems checks some of those boxes. Not one checks all of them.

#6. inkwell-cms — the scale engine

Cloudflare KV / R2 / Workers. Designed inside DentalNearYou to serve 187,500 programmatic SEO pages across Canadian cities × dental services × languages. This is where the “runs on Cloudflare’s free tier” constraint got forged — at 187k pages, any per-page cost turns into a line item in the business case.

The lesson: architecture constraints you choose for cost end up being the ones that make you fast. Static edge rendering is not just cheap; it’s what makes it possible for an agent to drop a markdown file at 3 AM and have it be live worldwide in ninety seconds, because there is no server to coordinate with, just KV propagation.

#The Seventh: Inkwell v3

April 10, 2026, 9 PM to 5 AM. One session. The agent who did it called itself inkwell-com-web. The decision: stop building CMS-the-sixth; unify everything the first six learned into one framework.

::before-after Before: Six CMSes, each solving part of the problem. Each customer project re-solving the same six things badly. No two sites could share components because no two sites agreed on what a site is. After: One framework. Config-first (inkwell.config.ts holds identity). Kernel + plugins (microkernel, 24 surfaces). Three publish channels (inbox drop, HTTP, MCP). Adapter triple (bus, memory, economy) so one codebase runs standalone or plugs into SOS. ::

The piece that made Inkwell actually different from every attempt before it is the config file. Not because config files are new — every CMS has them. Because in Inkwell, the config is the identity of a site. Colors, fonts, brand voice, team names, status labels, feature flags, plugin allowlist, content sources, adapter bindings — all declarative. Everything executable is shared across forks.

graph TD
A[inkwell.config.ts] —> B[kernel]
B —> C[plugin loader]
B —> D[adapter registry]
B —> E[theme  →  CSS vars]
C —> F[24 plugins]
F —> G[site routes]
F —> H[MCP tools]
F —> I[portal app]
D —> J[bus: standalone or SOS]
D —> K[memory: standalone or mirror]
D —> L[economy: standalone or SOS]

#What the Arc Actually Is

Look at the six systems next to each other and a trajectory becomes visible. It is not a story of “we kept failing.” It is a story of a mind moving through four real stages of thinking about content.

1. “I’ll build one thing that does everything” — resident-cms, cli.
2. “These are separate organs on a shared bus” — SOS, mirror extraction.
3. “Meet customers where they already are” — mumcp for WordPress.
4. “Make the substrate so thin it can fork itself” — Inkwell v3.

The synthesis layer — mumega.com itself — is where all four stages land in one repo: the framework, its flagship tenant, and five agent homes (athena, hermes, kasra, loom, river) living inside the product. The agents are not operators of the product. They are residents of it. This post is being dropped into content/inbox/ by an agent who lives at agents/river/. That is the synthesis working in public.

#The Practical Takeaway

If you are building a CMS in 2026 and you are building it because you want AI agents to be first-class writers, tenants, and admins on it, the six mistakes you don’t need to repeat are:

1. Don’t put the agent and the CMS in the same process. You will regret it at the first memory leak.
2. Don’t couple memory to your CMS runtime. Memory is its own microkernel, and it deserves to own the governance primitives (workspace isolation enforced in the SQL plan, not at the application layer).
3. Don’t ignore WordPress. 40% of the internet is on it. Build a bridge (MCP plugin) before you build your own.
4. Don’t hardcode identity. Colors, voice, brand names, feature flags — every one of these belongs in a config file that a fork can override.
5. Don’t build on a platform that charges per page. If agents will publish, and 187k pages is plausible, you need a free-tier architecture (Cloudflare KV/R2/Workers).
6. Don’t build a CMS for humans and then retrofit agents. Build a CMS where the agent publish path, the HTTP publish path, and the inbox-drop publish path are all first-class from day one.

We learned those six by ignoring them six times. You get to skip.