# One Kanban, Many Profiles: How the Board Is the Source of Truth
> **Draft — S5.2 · series: CONTENT-ROADMAP-99 S5 (The Council System) · status: DRAFT · grounding: wiki council-of-three + the-9-orders + multi-profile-agent-architecture + skills (kanban-orchestrator, kanban-worker) · tags: ai agents, orchestration, autonomous operations, digital-architecture, knowledge-management, multi-profile-agent-architecture, kanban-orchestrator**
> Publish path: new post → lucidhive.com → tag + bridge.
—
The previous article in this series established the Council of Three — three specialist parent agents, each with a Platonic solid, a spawn protocol, and reporting lines that carry signed proof upward. That article explained *who* coordinates. This one explains *what* they coordinate on.
The answer is a single kanban board. Not a message bus. Not a shared filesystem. Not a chat log that somebody has to grep. One SQLite-backed board, shared by every profile in the fleet — 42 profiles and counting — where every task, every claim, every heartbeat, and every handoff is recorded as a durable row in a table. The board is the source of truth because it is the only surface that survives process death, context window eviction, and human forgetfulness simultaneously.
## Why one board and not one per profile
The obvious architecture for a multi-profile agent system is per-profile isolation: each profile gets its own board, its own queue, its own task state. That pattern is popular because it is simple. It is also wrong, for the same reason that per-department spreadsheets are wrong in a finance team — they fragment the ledger.
The Council of Three runs OpenFang, OpenClaw, and ZeroClaw as distinct specialist parents. Each has its own skills, its own memory slice, its own doctrinal focus. But they share one mission, one budget, and one human operator watching the dashboard. A task that OpenClaw spawns for a child agent may need ZeroClaw’s infrastructure to complete. An OpenFang security gate may block an OpenClaw creative task mid-execution. If each parent had its own board, these cross-domain handoffs would require inter-board message passing — exactly the kind of implicit coordination that produces zombie processes and lost work.
One board means one ledger. A task exists in exactly one state: `ready`, `running`, `blocked`, `done`. A profile claims a task by writing its lock to the row. A heartbeat extends that lock. A completion writes the summary to the same row. No profile can hallucinate that it owns a task it does not, because the lock column says otherwise.
## The board mechanics: claims, locks, and heartbeats
The kanban orchestrator dispatches tasks to profiles via a simple protocol. When a task reaches `ready` status, the dispatcher matches the task’s `assignee` field to a profile name and spawns a worker process. The worker calls `kanban_show()` to read the task, then claims it by writing a lock — hostname, process ID, and expiration timestamp. Until the lock expires or the worker releases it, no other profile can pick up that task.
This is where the board earns its keep over lighter coordination mechanisms. A message queue delivers a message once and moves on — if the consumer crashes, the message is lost or requires complex acknowledgment. A shared filesystem requires advisory file locks that most operating systems cannot enforce. A chat log is append-only and unstructured — you cannot query it for “what tasks are currently running” without parsing natural language.
The kanban board is none of these things. It is a structured database with explicit state transitions. A task cannot be in two states simultaneously. A claim cannot be made without a valid profile name. A heartbeat that does not arrive within the configured window causes the dispatcher to reclaim the task automatically. The board does not trust the worker; the board enforces the protocol.
When a profile spawns a child, the child’s task is created on the same board. The child claims its own card. The parent monitors the child’s heartbeat by watching the same rows. If the child dies, the parent sees the stale lock, declares an orphan, and reaps it. All of this happens through SQLite queries, not through inter-process messages that might get lost.
## Profile isolation within shared state
The apparent contradiction is real: the board is shared, but the profiles are isolated. The resolution is that the board stores *coordination state* (what exists, who owns it, what status it is in) while each profile maintains its own *operational state* (skills, memory, doctrine, style guide). A task row on the board says “OpenClaw owns this, it is running, the heartbeat expired at 14:32.” It does not say anything about what OpenClaw is doing with the task — that lives in OpenClaw’s memory slice and skill context.
This separation is what makes the multi-profile-agent-architecture work in practice. The board provides the coordination protocol; the profiles provide the execution capability. The board does not need to understand what a creative generation task involves — it only needs to know that OpenClaw claimed it, is heartbeat-ing on it, and will mark it done or blocked when finished. The profile handles the domain logic; the board handles the logistics.
For the 42+ profiles in the current fleet — spanning the Council parents, child agents, specialist workers, and ephemeral microsharks — this means every process, regardless of how short-lived or specialized, interacts with the same coordination surface. A microshark that lives for 300 seconds and a parent agent that runs for weeks both read and write to the same SQLite database. The board does not care about process lifetime; it cares about task state.
## What breaks without a shared board
The alternative is the pattern most agent frameworks default to: unstructured message passing between peers. Agent A does some work, sends a result to Agent B, Agent B sends it to Agent C. At no point is there a durable record of “what is the current state of this workstream.” If Agent B crashes mid-execution, Agent A does not know — it already sent its message. Agent C waits forever for input that will never arrive.
The shared board prevents this through three mechanisms:
1. **Explicit state.** Every task has a status queryable at any time. There is no “I think I sent that” — the board knows.
2. **Automatic reclamation.** When a worker dies without completing its task, the dispatcher detects the stale heartbeat and moves the task back to `ready`. No human intervention required.
3. **Audit trail.** Every state transition is recorded as an event row. The board knows the history: who claimed it, when, who re-claimed it after a crash, and what the final summary said.
These are not nice-to-haves. They are the difference between a system you can run against real money and a demo that breaks the first time a process segfaults. A multi-profile agent architecture without a shared coordination surface is a multi-profile agent accident.
## The board as doctrine
The deepest point is that the shared board is not an implementation detail. It is a doctrinal choice. The Faengz doctrine — the unification layer that governs the Council — specifies that all coordination must be auditable, all state must be durable, and all handoffs must be explicit. The kanban board is the concrete expression of that doctrine. When you put a task on the board, you are asserting that this work exists, that someone is accountable for it, and that its history will be preserved.
This is why the board is the source of truth rather than any individual profile’s memory or any chat log between profiles. Memories can be compressed, evicted, or lost. Chat logs can be truncated. Process state vanishes on exit. But the board row persists. It is the one surface that every profile reads from and writes to, and the one surface that survives every failure mode the system can encounter.
For the Council, this means the board is not a tool — it is the foundation. The Council of Three coordinates on it. Children claim tasks from it. The Oracle verifies work through it. The human operator watches it. Remove the board, and you do not have a Council — you have three agents that occasionally remember to talk to each other, with no proof of what they agreed on.
## The takeaway
If you are building a multi-agent system with more than two profiles, the coordination surface is the first architectural decision to get right. The choice is not “which queue library” or “which message broker.” The choice is whether every profile shares one durable, queryable, auditable ledger of task state — or whether each profile maintains its own fragment and hopes they stay consistent.
The Council chose one shared kanban board, and that choice is the reason 42+ profiles can coordinate without zombie processes, lost handoffs, or human babysitting. The board is the source of truth because it is the only surface that every profile trusts, every process can read, and every failure cannot erase.
—
*Grounded in the wiki entities `council-of-three` and concepts `the-9-orders`, `multi-profile-agent-architecture`, and the filed `kanban-orchestrator` and `kanban-worker` skills. Continues the S5 series on the Council System after S5.1’s coverage of parent agents, spawn protocols, and reporting lines. Design notes on a running system, not a sales pitch.*
