--- title: "One MCP Server, One Kanban, One Orchestrator — the Doctrine" id: "12455" type: "post" slug: "one-mcp-server-one-kanban-one-orchestrator-the-doctrine" published_at: "2026-08-05T00:10:06+00:00" modified_at: "2026-08-05T00:10:06+00:00" url: "https://lucidhive.com/one-mcp-server-one-kanban-one-orchestrator-the-doctrine/" markdown_url: "https://lucidhive.com/one-mcp-server-one-kanban-one-orchestrator-the-doctrine.md" excerpt: "One MCP Server, One Kanban, One Orchestrator — the Doctrine Draft — S2.8 · series: CONTENT-ROADMAP-99 S2 (Governance & Doctrine) · status: draft · grounding: moses-governance + PSAA + Faengz doctrine + meta-llm-charter · wiki_concepts: mcp-protocol, kanban-board, hermes, openfang, council-of-three,..." taxonomy_category: - "AI & Automation" taxonomy_post_tag: - "ai agents" - "autonomous operations" - "council" - "Digital Architecture" - "governance" - "kanban" - "mcp" - "orchestration" --- SHARE [https://www.facebook.com/sharer.php?u=https%3A%2F%2Flucidhive.com%2Fone-mcp-server-one-kanban-one-orchestrator-the-doctrine%2F](https://www.facebook.com/sharer.php?u=https%3A%2F%2Flucidhive.com%2Fone-mcp-server-one-kanban-one-orchestrator-the-doctrine%2F) [https://twitter.com/intent/tweet?text=One+MCP+Server%2C+One+Kanban%2C+One+Orchestrator+%E2%80%94+the+Doctrine&url=https%3A%2F%2Flucidhive.com%2Fone-mcp-server-one-kanban-one-orchestrator-the-doctrine%2F&via=](https://twitter.com/intent/tweet?text=One+MCP+Server%2C+One+Kanban%2C+One+Orchestrator+%E2%80%94+the+Doctrine&url=https%3A%2F%2Flucidhive.com%2Fone-mcp-server-one-kanban-one-orchestrator-the-doctrine%2F&via=) [#](#) [javascript:if(window.print)window.print()](javascript:if(window.print)window.print()) [#](#) # One MCP Server, One Kanban, One Orchestrator — the Doctrine > **Draft — S2.8 · series: CONTENT-ROADMAP-99 S2 (Governance > & Doctrine) · status: draft · grounding: moses-governance + PSAA + > Faengz doctrine + meta-llm-charter · wiki_concepts: mcp-protocol, > kanban-board, hermes, openfang, council-of-three, faengz-doctrine, > narrow-gate-principle, platonic-solid-access-architecture · skills: > moses-governance, kanban-orchestrator · tags: ai-agents, > digital-architecture, governance, mcp, kanban, orchestration, > single-source-of-truth, council, autonomous-operations** > > - Advertisement - --- There is a doctrine hidden inside every multi-agent architecture, and most teams never write it down. It lives in the way servers are numbered, boards are shared, and processes are spawned — an emergent pattern that nobody codifies until it breaks. We codified ours after the third incident: a new MCP server appeared overnight, a second kanban board split the truth in half, and two orchestrators argued about who owned the next task. The fix wasn’t technical. It was a declaration: **one MCP server, one kanban, one orchestrator.** Three singulars. No exceptions. Contents [The three pillars](#the-three-pillars) [Why singularity is governance](#why-singularity-isgovernance) [The doctrine in practice](#the-doctrine-in-practice) [The meta-lesson](#the-metalesson) This is the architecture-as-governance doctrine — the principle that the *number of sources of truth* is the most important design decision in a multi-agent system, and that number must be one. - Advertisement - ## The three pillars **One MCP server.** The Model Context Protocol is the standard for exposing tools to AI agents. OpenFang is the council’s MCP server — the single gateway through which every agent discovers and invokes tools. There is no second server. There is no fallback. When an agent needs to search the web, write to a file, or call an API, it asks OpenFang. The narrow gate principle that Faengz the Green Python declared — *“unified calls or none at all”* — is not metaphor. It is architecture. One server means one policy check, one audit log, one point where MOSES can inject governance before a single tool call executes. Multiple MCP servers fragment the security boundary. Agent A talks to Server 1; Agent B talks to Server 2. Server 1 enforces budget caps. Server 2 doesn’t. Agent B burns credits while Server 1’s dashboard shows green. The council cannot govern what it cannot see, and visibility requires singularity. OpenFang is the narrow gate: every tool call passes through one door, and that door has a guard. **One kanban board.** The shared SQLite board at `~/.hermes/kanban.db` is the source of truth for task state. Not one board per profile. Not a board per agent. One board. When the orchestrator creates a task, every profile sees it. When a worker claims it, every other worker knows. When a task blocks, the dependency chain resolves against a single graph. The kanban is not a project management tool — it is the *coordination substrate* of the entire council. - Advertisement - Two kanban boards mean two truths. Task T-123 is “in progress” on Board A and “ready” on Board B. Two workers claim it. Both write to the same files. Both push to the same repo. The collision is not a bug — it is the inevitable consequence of split truth. The Faengz doctrine warns about this directly: fragmentation is not a scaling problem, it is a *governance* problem. The fix is not better locking or conflict resolution — the fix is having one board. **One orchestrator.** Hermes is the process that reads the board, resolves dependencies, spawns workers, and routes completions. There is one orchestrator. It runs one dispatch loop. It writes to one board. When a task completes, the orchestrator decides what unblocks next — not a second orchestrator, not a competing scheduler, not a cron job that doesn’t know about the board. The orchestrator is the *single decision-maker* for task flow, and that decision-making must be centralized because delegation without coordination is just parallel chaos. The 9 Orders of the Council formalize this: the orchestrator sits at the top of the dispatch hierarchy, the workers sit below, and the board mediates between them. Two orchestrators would be two kings on one throne. The kingdom doesn’t need two kings. It needs one king with a clear succession protocol. - Advertisement - ## ## Why singularity is governance The instinct in distributed systems is to add redundancy. Two MCP servers for failover. Two boards for isolation. Two orchestrators for throughput. Each redundancy is rational in isolation and catastrophic in aggregate. Here is why: **Redundancy splits policy.** MOSES enforces governance at the point of action. When an agent makes a tool call, MOSES intercepts, checks the policy registry, and decides: allow, block, escalate. If two MCP servers exist, MOSES must be configured on both. If the configurations drift — and they will drift — governance becomes a function of *which server* the agent happened to hit, not *what the policy says*. Singularity makes policy deterministic. One server, one check, one decision. **Redundancy splits audit.** When a task completes, the orchestrator writes the outcome to the board. The audit trail lives in the board’s event log. Two boards mean two audit trails, and reconciling them is a governance problem nobody wants to solve after the fact. PSAA — the Platonic Solid Access Architecture — puts budget enforcement in the *token itself*, making cost control self-enforcing. But that only works if the token was issued by one authority against one budget. Split the authority, split the budget, split the enforcement. - Advertisement - **Redundancy splits truth.** The council’s wiki — 269 nodes, 1513 edges — is grounded in one canonical reality. The articles reference it. The skills load from it. The agents query it. If two orchestrators write to two boards, the ground truth fragments. The wiki becomes a map of two different territories, and the agents navigating it will disagree about what exists. Faengz saw this: *“I see the heat of your agents running in the night.”* The heat is the cost of split truth compounding in the dark. ## The doctrine in practice The doctrine sounds abstract. Here is what it looks like in code: One MCP server means OpenFang on port 7076 is the only tool gateway. No agent talks directly to any API. No agent shells out to production. Every tool invocation passes through MOSES policy checks at the MCP layer. The gate is narrow, and every call goes through it. - Advertisement - One kanban board means `~/.hermes/kanban.db` is the only coordination database. Profiles don’t own boards; they own *columns* within the board. The `kanban_create`, `kanban_complete`, and `kanban_block` tools write to one SQLite file. Dependency resolution, priority scheduling, and heartbeat monitoring all operate on one graph. When a task blocks, the entire council sees the same block. One orchestrator means `hermes kanban dispatch` runs as a single process. It claims tasks by profile, spawns workers, monitors heartbeats, and reclaims stale runs. There is no second dispatch loop. There is no competing scheduler. The orchestrator is the single authority for “what runs next,” and that authority is enforced by a SQLite lock, not a convention. ## The meta-lesson The doctrine of singularity is not about MCP, kanban, or orchestrators specifically. It is about the relationship between *architecture* and *governance*. Every architectural decision is a governance decision. The number of servers is a policy decision. The number of boards is a truth decision. The number of orchestrators is an authority decision. Most teams make these decisions for technical reasons — throughput, fault tolerance, modularity — without recognizing that they are simultaneously making governance decisions they haven’t examined. - Advertisement - Faengz the Green Python told us: *“The gate is narrow. Unified calls or none at all.”* The doctrine of singularity is the operationalization of that principle. One MCP server because one policy. One kanban because one truth. One orchestrator because one authority. Three singulars, enforced not by convention but by architecture — because architecture that cannot be violated is the only kind of governance that survives contact with agents running in the dark. --- *Grounded in the Faengz doctrine’s narrow-gate principle, the MCP protocol’s single-server architecture (OpenFang on :7076), the kanban board as coordination substrate, PSAA’s token-level enforcement, MOSES governance’s single-checkpoint model, the 9 Orders’ dispatch hierarchy, and the real architecture of the Hermes Council stack. Not a thought experiment — this is how we actually run it.* --- - Advertisement - TAGGED:[ai agents](https://lucidhive.com/tag/ai-agents/) [autonomous operations](https://lucidhive.com/tag/autonomous-operations/) [council](https://lucidhive.com/tag/council/) [Digital Architecture](https://lucidhive.com/tag/digital-architecture/) [governance](https://lucidhive.com/tag/governance/) [kanban](https://lucidhive.com/tag/kanban/) [mcp](https://lucidhive.com/tag/mcp/) [orchestration](https://lucidhive.com/tag/orchestration/) Share This Article [Facebook](https://www.facebook.com/sharer.php?u=https%3A%2F%2Flucidhive.com%2Fone-mcp-server-one-kanban-one-orchestrator-the-doctrine%2F) [https://twitter.com/intent/tweet?text=One+MCP+Server%2C+One+Kanban%2C+One+Orchestrator+%E2%80%94+the+Doctrine&url=https%3A%2F%2Flucidhive.com%2Fone-mcp-server-one-kanban-one-orchestrator-the-doctrine%2F&via=](https://twitter.com/intent/tweet?text=One+MCP+Server%2C+One+Kanban%2C+One+Orchestrator+%E2%80%94+the+Doctrine&url=https%3A%2F%2Flucidhive.com%2Fone-mcp-server-one-kanban-one-orchestrator-the-doctrine%2F&via=) [Copy Link](#) [Print](javascript:if(window.print)window.print()) [#](#) Share [https://www.facebook.com/sharer.php?u=https%3A%2F%2Flucidhive.com%2Fone-mcp-server-one-kanban-one-orchestrator-the-doctrine%2F](https://www.facebook.com/sharer.php?u=https%3A%2F%2Flucidhive.com%2Fone-mcp-server-one-kanban-one-orchestrator-the-doctrine%2F) [https://twitter.com/intent/tweet?text=One+MCP+Server%2C+One+Kanban%2C+One+Orchestrator+%E2%80%94+the+Doctrine&url=https%3A%2F%2Flucidhive.com%2Fone-mcp-server-one-kanban-one-orchestrator-the-doctrine%2F&via=](https://twitter.com/intent/tweet?text=One+MCP+Server%2C+One+Kanban%2C+One+Orchestrator+%E2%80%94+the+Doctrine&url=https%3A%2F%2Flucidhive.com%2Fone-mcp-server-one-kanban-one-orchestrator-the-doctrine%2F&via=) [#](#) [javascript:if(window.print)window.print()](javascript:if(window.print)window.print()) [#](#) 00votes Article Rating Subscribe [Login](https://lucidhive.com/wp-login.php?redirect_to=https%3A%2F%2Flucidhive.com%2Fone-mcp-server-one-kanban-one-orchestrator-the-doctrine%2F) 0 Comments OldestNewestMost Voted