When the Mesh Meets the Board
The S1 series built the mesh: an Erlang-inspired actor system where each agent is a supervised process, each profile a gen_server with a PID, a port, and a restart policy. The S5 series built the dispatch: a kanban board that claims tasks, heartbeats liveness, blocks on ambiguity, and recovers from crash. Both systems solve coordination. Neither was designed alone. This bridge article examines what happens when you connect them — where the mesh’s process architecture meets the council’s task protocol, and why the intersection is where orchestration actually lives.
The mesh provides the body; the board provides the pulse
A mesh without a dispatch surface is a forest of processes with no shared sense of purpose. The Dodecahedron supervisor can restart crashed workers, the Icosahedra can dissolve after sub-tasks, and the narrow gate can audit every tool call — but none of that answers the question: what should be working right now? The mesh is anatomy. The kanban board is physiology.
S1.3 demonstrated the supervision tree: when a profile actor crashes, its supervisor detects the failure and restarts it according to the restart intensity. S5.7 showed the complement: when a worker crashes mid-task, the dispatcher detects the stale heartbeat, reclaims the task, and spawns a fresh worker that reads the comment thread to pick up where the last one left off. These are two layers of the same resilience doctrine — one operates on processes, the other on work units — and neither is complete without the other.
The process layer handles how an agent lives: its PID, its memory budget, its restart policy, its access tier within the platonic hierarchy. The dispatch layer handles what it does: which task it claims, what progress it reports, when it blocks for human judgment. Mesh-orchestration is the discipline of keeping these two layers aligned — ensuring that every running process has a task, and every task has a process capable of executing it.
Claims are process-level contracts
When a worker calls kanban_show() and then claims a task, it writes a lock containing hostname, PID, and expiration. This is not just a board operation — it is a process-level contract. The PID in that lock is the same PID the Dodecahedron supervisor registered. The hostname is the same machine where the supervisor tree lives. If the process dies, the lock expires; if the lock expires, the supervisor’s next restart spawns a fresh process that reads the old thread.
This is the mesh-orchestration seam. The claim protocol on the board mirrors the supervision protocol in the BEAM: both assume failure, both preserve state across restarts, both route work to replacement processes without human intervention. The difference is granularity. Supervision restarts a process; dispatch reclaims a task. A process can restart empty-handed while its task sits in blocked waiting for a human answer. The two systems must agree on which layer owns the recovery decision.
In the Council’s implementation, the answer is explicit: the board owns task state; the mesh owns process state. A crashed worker does not attempt to fix its own task — it dies, and the dispatcher decides what happens next. This separation is deliberate. A worker that tries to recover its own state while crashing produces inconsistent results; a worker that dies cleanly and lets the dispatcher reassess produces an auditable trail.
Heartbeats bridge two failure domains
The heartbeat is the mechanism that connects process liveness to task progress. When a worker heartbeats, it extends its lock on the board and signals to the supervisor tree that the process is alive. A process that stops heartbeating is both a dead worker (from the board’s perspective) and a potentially hung process (from the supervisor’s perspective).
This dual signal is what makes mesh-orchestration more than process management. The supervisor can detect a crashed process via exit signals; the dispatcher can detect a stalled task via heartbeat expiry. But a process that is alive and busy looks identical to a process that is alive and stuck — both are heartbeating, or both are not. The mesh-orchestration layer must distinguish between “process alive, task progressing” and “process alive, task deadlocked.” In practice, this means the heartbeat note must carry task-level semantics — not just “I’m alive” but “I’m on step 3 of 7, epoch 12, loss 0.31” — so the dispatcher can evaluate progress, not just presence.
The narrow gate is where both layers converge
S1.8 established the narrow gate: one MCP server, one tool channel, every call from every order transiting a single seam. S5.7 established the auto-block: when a worker cannot resolve a situation autonomously, it stops and waits rather than guessing. These converge at the gate. A worker that blocks is a process that has decided its tool access is insufficient for the task at hand — it needs credentials it does not hold, or information that only the human operator can provide.
The narrow gate enforces this at the mesh level: no process may bypass the gate to acquire tools it was not authorized to hold. The auto-block enforces it at the dispatch level: no worker may proceed with incomplete information. Together, they form a two-layer authorization lattice. The mesh says “you may not touch that tool”; the board says “you may not proceed without that answer.” Both are constraints; both are recoverable; both preserve the audit trail that makes the system self-correcting.
What mesh-orchestration means in practice
When you deploy a 42-profile fleet, mesh-orchestration is the operating discipline that keeps the two layers from drifting apart. It means:
Every process has a task assignment. A supervisor that restarts a process without a task creates a zombie — alive but idle, consuming resources without producing output. The dispatcher must be aware of process restarts and reassign tasks to replacement processes promptly.
Every task has a capable process. A task assigned to a profile whose process is crashed or restarted must wait for the mesh to restore the process before the dispatcher can spawn a worker. If the mesh is slow to restart, the task sits in ready — and the human operator sees the delay on the dashboard.
Recovery is layered, not duplicated. The mesh handles process crash; the dispatch handles task failure. Neither attempts the other’s job. A process that crashes loses its PID and memory; a task that fails loses its lock and progress. Both are recoverable; both produce audit trails; neither requires human intervention for transient failures.
The audit trail is the shared memory. Every process restart, every task reclaim, every heartbeat, every block — all recorded on the board, all visible on the dashboard, all queryable after the fact. The mesh and the board do not share memory; they share a record. That record is what makes the system coherent across 42 profiles running simultaneously.
The bridge is the operating system
The S1 series describes the mesh as a deployment model: platonic solids as process lifetimes, the narrow gate as the enforcement seam, the Nonagon as the self-correction loop. The S5 series describes the dispatch as a coordination protocol: claims, heartbeats, blocks, recovery. Mesh-orchestration is the bridge between them — the discipline that keeps the mesh’s process architecture aligned with the board’s task protocol.
Neither layer alone produces orchestration. The mesh without the board is a supervised forest of processes with no shared purpose. The board without the mesh is a coordination surface with no executing processes. Together, they produce something that neither architecture alone can: a fleet that survives process death, routes work to the right capability, stops rather than guesses when it runs out of information, and recovers with a complete audit trail. That is what mesh-orchestration means. Not a diagram. Not a protocol. An operating system.
Series entry: B.mesh-orchestration.03 — bridge between S1 (The Mesh) and S5 (The Council System). Grounded in the S1 Erlang actor mesh architecture (supervision trees, gen_server, PID dispatch, platonic hierarchy, narrow gate) and the S5 Council dispatch protocol (kanban claims, heartbeats, auto-block, recovery). For builders of multi-agent systems: the hard part is not the architecture or the protocol — it is keeping them aligned.
