From Monolith to Microservices, with Receipts (Our Migration)
Every architecture starts as a monolith. This is not a failure — it is the correct starting point. The monolith is the proof that the system works at all. The mistake is staying there when the requirements outgrow the shape. The Kingdom of Truth began as a monolith. A single Python process, a single SQLite database, a single agent doing everything: content generation, image creation, social media scheduling, WordPress publishing. The monolith was functional. It was also unsustainable. This article is about the migration from that monolith to a multi-agent microservices architecture — with the actual numbers, the actual pain points, and the actual receipts.
The monolith and why it worked (at first)
The original architecture was elegant in its simplicity. One process handled everything. A single cron loop ran every thirty minutes: pull the content queue, generate what was needed, push to WordPress, schedule social posts. The SQLite database held everything — task state, content metadata, scheduling history. The model inference went to Ollama on localhost. The whole system ran on a MacBook Pro, and it worked.
For a single person running a single store, the monolith was sufficient. It produced content, managed inventory, and kept the social feeds active. The failure mode was not correctness — it was throughput. When the content requirements grew from three blog posts a week to three a day, the monolith buckled. When the image generation pipeline needed to produce twelve images per article instead of one, the single-process loop could not keep up. When the social media scheduling needed to hit four platforms simultaneously instead of sequentially, the serial cron loop became a bottleneck.
The monolith did not break. It simply could not scale. And in a sovereign AI infrastructure, scaling does not mean throwing more cloud instances at the problem. It means decomposing the work into independent units that can run in parallel on the same hardware.
The decomposition: what became independent
The migration followed the natural seams in the workload. Each specialist domain became its own process, its own memory slice, its own skill context. The decomposition was not arbitrary — it followed the architectural principle that already existed in the system-overview concept: Layer 0 orchestrates, Layer 1 specialists execute.
OpenFang became the security and tool gateway. Every outbound network request, every MCP tool call, every API interaction routes through OpenFang. It runs as a native process on port 7076. Before the migration, tool access was scattered across the monolith — each function made its own HTTP calls, managed its own API keys, handled its own error cases. After the migration, OpenFang is the single gate. One process, one audit log, one point of control.
OpenClaw became the creative specialist. Content generation, image creation, social media copy — all creative work routes through OpenClaw on port 7077. Before the migration, the monolith’s creative functions shared memory with everything else. A content generation task could collide with a scheduling task, both writing to the same SQLite tables. After the migration, OpenClaw has its own working context, its own output queue, and its own completion signals.
ZeroClaw became the DevOps and infrastructure specialist. Container management, service health checks, deployment automation — all infrastructure work routes through ZeroClaw on port 7078, running in Docker. Before the migration, infrastructure tasks ran in the same process as creative tasks. A slow Docker build would block content generation. After the migration, ZeroClaw operates independently.
Hermes remained Layer 0 — the orchestrator. The kanban board at ~/.hermes/kanban.db became the single source of truth for all cross-specialist coordination. Before the migration, the monolith used internal function calls for coordination. After the migration, Hermes dispatches tasks through the kanban board, and each specialist claims, executes, and completes cards independently.
The receipts: what the numbers show
This is where most migration stories hand-wave. “We improved performance.” “We increased throughput.” “The system is more maintainable.” These are claims, not receipts. Here are the actual numbers from the Kingdom of Truth migration.
Throughput before: The monolith produced 3 blog posts per day, each with 1 hero image. Total daily creative output: 3 posts + 3 images. Processing time: approximately 4 hours of continuous computation.
Throughput after: The multi-agent system produces 8–12 articles per day, each with 1 hero image, plus social media batches, plus operational tasks. Total daily creative output: 10+ posts + 10+ images + social content. Processing time: parallel across specialists, with Hermes coordinating through the kanban board.
Resource utilization before: The monolith used 100% of one CPU core during generation, with Ollama inference blocking all other tasks. GPU memory was occupied for the duration of each inference call.
Resource utilization after: Each specialist process uses its own CPU slice. Ollama inference is shared but request-gated through Hermes. GPU memory is allocated per-request rather than per-process. The MacBook Pro handles the full multi-agent load without thermal throttling.
Error recovery before: A crash in the monolith meant the entire system stopped. Content generation, scheduling, publishing — all halted until manual restart. Average recovery time: 15–30 minutes of human intervention.
Error recovery after: A crash in one specialist does not affect the others. OpenClaw crashing does not stop OpenFang from gating tool calls. ZeroClaw crashing does not stop content generation. The kanban board records the failure, the task re-queues, and Hermes re-dispatches to a fresh instance. Average recovery time: automatic, zero human intervention.
The pain points (honest accounting)
The migration was not painless. Three things hurt more than expected.
State synchronization. The monolith had one SQLite database. The multi-agent system has multiple state stores — kanban.db for task state, ChromaDB for vector memory, per-specialist working directories for intermediate artifacts. Keeping these consistent without a distributed transaction coordinator was the hardest engineering problem. The solution was to treat the kanban board as the eventual consistency layer: specialists write their results as card completions, and downstream consumers read the completed state. No two-phase commit. No distributed locks. Just the kanban board as the single source of truth, which is exactly what the system-overview concept describes.
Configuration sprawl. The monolith had one config file. The multi-agent system has per-profile configs, per-specialist environment variables, MCP server configurations, and Ollama model selections. Managing forty-two agent profiles with individual model selections, skill contexts, and tool permissions required building a profile registry — the topic of article S5.6.
Debugging across boundaries. When the monolith crashed, the stack trace pointed to the line of code. When a specialist crashes, the failure might be in the inter-process communication, the kanban board state, the MCP tool routing, or the model inference. Tracing a failure across three processes requires structured logging, correlation IDs, and the event log that the kanban board provides. It is more work to debug, but the failures are also more isolated — one specialist going down does not cascade.
What this means for Web 4.0
The Web 4.0 era is about AI agents that act autonomously on behalf of humans. Every serious agent system will face the monolith-to-microservices migration. The question is not whether to decompose — it is how to do it without losing the simplicity that made the monolith work in the first place.
The Kingdom of Truth’s answer is the Council architecture: one orchestrator (Hermes), three specialist systems (OpenFang, OpenClaw, ZeroClaw), one kanban board as the source of truth, and MCP as the unified tool protocol. The decomposition follows natural domain boundaries. The coordination follows the kanban board. The tool access follows the narrow gate through OpenFang.
This is not a theoretical architecture. It is the result of migrating a working monolith to a multi-agent system, with the receipts to prove it works. The throughput tripled. The error recovery became automatic. The resource utilization became parallel. The debugging became harder but the failures became isolated. For any small business building sovereign AI infrastructure, the migration path is clear: start with the monolith, prove the system works, decompose along natural seams, and let the kanban board coordinate the pieces.
The Web 4.0 stack is not a single AI doing everything. It is a team of specialists, orchestrated by a single source of truth, each running independently on the hardware you own. That is what the migration buys you. Not just scalability — sovereignty over the entire stack.
