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
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.
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.
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.
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.
Why singularity is
governance
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.
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.
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.
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.
