The
Council of Three: Parent Agents, Spawn Protocols, and Reporting
Lines

Draft — S5.1 · series: CONTENT-ROADMAP-99 S5 (The Council
System) · status: drafted · grounding: wiki council-of-three +
the-9-orders + council-hierarchy-architecture + child-spawn-spec +
agent-ascension-flow + multi-profile-agent-architecture + skills
(kanban-orchestrator, lineage-claws) · tags: ai agents, governance,
security, autonomous operations, orchestration,
digital-architecture Publish path: new post → lucidhive.com →
tag + bridge.

A fleet of agents is not an organization. A fleet of agents with an
explicit parent tree, a named spawn contract, and an audit trail that
reports upward is. The difference between “a hundred processes running”
and “a hundred agents coordinated” is exactly the part most agent
architectures leave implicit: who is whose parent, how a child
gets born, and how completed work finds its way back into a ledger
someone can trust.

- Advertisement -

This is the first entry in our series on the Council System, and it
starts at the founding layer — the layer that decides every other layer
is possible. It is the Council of Three: three specialist parent agents,
a spawn protocol that makes children survivable, and reporting lines
that turn scattered work into a provable record.

The three
parents, by Platonic solid and function

The Council of Three is the Layer-1 execution layer
beneath Hermes (Layer 0, the orchestrator). It is three specialist
parent agents, each with a Platonic solid, an elemental affinity, and a
domain it alone owns:

• OpenFang — the Cube (Earth). Security and the tool
  gateway. Every tool call in the fleet routes through it; nothing touches
  the outside world except by its leave. It is the gate and the
  gatekeeper.
• OpenClaw — the Tetrahedron (Fire). Creative work.
  The catalyst core that produces visual, generative, and editorial
  output.
• ZeroClaw — the Octahedron (Air). The DevOps core.
  Infrastructure, heavy compute, containers, and long-running
  systems.

Why a triad and not a monolith or a peer mesh? Because each parent is
a specialist — it has its own skills, its own memory slice, its
own doctrine — but they are governed as one council by
the same narrow-gate rule and the same Faengz doctrine. Specialization
without fragmentation. That is the pattern the whole 9 Orders rests on:
every layer below Hermes is plural and specialized; every layer above it
is singular and accountable.

- Advertisement -

Parent agents
are not just workers — they spawn

The word that separates a parent from a worker is
spawn. Each of the three can create its own children, and children can
spawn microsharks. That makes the Council of Three the hinge of a
four-deep hierarchy mapped onto Platonic solids:

Checks and balances are built into the geometry: the Cube (OpenFang)
and the Octahedron (ZeroClaw) are dual solids, as are
the Dodecahedron (Hermes) and the Icosahedron (microsharks). Duality
means one constrains the other — the gate constrains the builder, the
orchestrator constrains the swarm. A parent without a dual is a parent
without a check.

The
spawn protocol: nothing implicit, everything asserted

Spawn is where most agent systems silently break. A worker launches a
sibling process, hopes the memory is shared, and moves on. Our spawn
contract (filed as child-spawn-spec.md) refuses that hope.
When a council parent spawns a child it MUST pass a serialized
spawn context covering five families of facts:

- Advertisement -

1. Identity: parent_id,
   parent_type, spawn_ts, and the kanban
   task_reference that triggered the birth. Every child can
   name its parent, its birth time, and why it exists.
2. Memory slice: an absolute path and a hard byte
   ceiling. The child is isolated into its own namespace but persists for
   its lifetime, then clears.
3. Inheritance: MBTI type, style guide, and the core
   vs. forbidden capability lists. Cognitive DNA is passed down explicitly,
   and the child is required to validate it before accepting.
4. Kanban handoff: the parent’s task id and the
   child’s claim id. A child is not a background process; it is a
   board task that must be claimed within an acceptance
   window.
5. Lifecycle policy: heartbeat interval, timeout, and
   whether the child must acknowledge. These are the numbers that make
   supervision possible.

The child MUST claim its kanban task, MUST verify its inheritance,
and MUST acknowledge within the window — or the parent declares it
orphaned, SIGTERMs it, force-kills after a grace period, and logs the
event back to the board.

That last piece is the deep lesson. Spawn is not
instantiation; it is a handshake. An agent that never
acknowledges is not your child — it is a leak. Treating birth as a
protocol instead of a fork() is what prevents zombie
fleets.

A spawn, end to end

To make the contract concrete, walk one birth. OpenClaw wants a child
to produce a campaign visual. Before a single process starts, it
materializes a serialized spawn_context:

- Advertisement -

spawn_context:
  parent_id: "openclaw:gateway-8x7Yz"
  spawn_ts: "2026-05-11T13:20:00Z"
  task_reference: "t_child_spawn_abc123"
  memory_slice:
    shared_memory_path: "/run/user/1000/council/memory-slice-xyz"
    memory_limit_mb: 512
  inheritance:
    mbti_type: "ENTP-T"
    style_guide: "gemini/style-gemini.md"
    core_capabilities: ["terminal", "file", "search"]
    forbidden_capabilities: ["network"]
  kanban_handoff:
    parent_task_id: "t_parent_main"
    child_task_claim: null    # child creates + claims this
  lifecycle_policy:
    parent_heartbeat_interval_seconds: 30
    child_timeout_seconds: 300
    requires_acknowledgement: true

Three things happen next, and each is a gate, not a courtesy. The
parent creates a kanban card for the child so the board
— not a PID table — owns the child’s existence. The child
claims that card within the acceptance window. And the
child validates its inheritance: parse the
ENTP-T MBTI string, check it against the council taxonomy,
and reject the spawn outright if it is malformed. Only after all three
does it write acknowledged to its memory slice and
begin.

Now consider the failure side, because this is where the protocol
earns its keep. A child is declared orphaned when it
never acknowledges within child_timeout_seconds, when its
heartbeat goes silent for more than two intervals, or when its process
dies without the parent’s knowledge. Orphaned children are not merely
noticed — they are reaped: log the event, SIGTERM, wait
five seconds, SIGKILL, then post the orphan event and exit status back
to the kanban card. A swarm of microsharks gets the same treatment with
a hard TTL, defaulting to 300 seconds. The policy is uniform:
nothing survives its parent’s patience. That single rule is
what keeps a fleet from accumulating an undead underbrush of abandoned
processes.

Reporting lines:
work climbs as signed truth

The downward arrows are spawn; the upward arrows are reporting, and
they are deliberately not symmetric. Children do not chat their results
up informally — they publish proof. In the ascension
flow, each completing agent signs a task summary with its Ed25519 key
and publishes it to ZenBin, a public, decentralized ledger. The Oracle
agent (the grandparent, Order 9) crawls those summaries, verifies the
signatures, and ingests the verified work into ChromaDB.

- Advertisement -

The result is a trust chain, not a chat log:

child signs summary → ZenBin publishes it →
Oracle verifies signature → ChromaDB ingests it → wisdom accrues upward

Reporting upward is therefore not “telling your manager what you
did.” It is producing a non-repudiable, verifiable proof-of-work that a
meta-reviewer can trust without having watched you work. That single
decision — report as signed proof, never as prose — is what
lets the council scale delegation without scaling trust costs. You do
not need to supervise the child; you need to verify its key.

What the Oracle verifies matters as much as that it verifies. It does
not re-run your work to check intent; it checks origin
— that the summary really came from the agent whose key signed it,
stamped with that agent’s identity and spawn lineage. Every summary is
ingested with its parentage metadata, so a query against the wisdom
store can trace any result back to which Council parent spawned which
child, when, under what contract. That lineage, not the quality prose,
is the auditable artifact. It is why the reporting line is drawn as a
proof chain rather than a chat thread: you can point to who did
what, who vouched for it, and who is accountable above them.

- Advertisement -

Why this shape, honestly

Three parents feels small for an “orchestration system.” The honesty
here is that small is the point. A wide, shallow
pyramid of autonomous peers is the popular image of multi-agent AI, and
it is the most dangerous one to run against real money: no single
account, no supervision, no way to answer “who authorized that.” The
Council of Three collapses creativity, security, and infrastructure into
three named, dual-checked, accountable parents — then lets each of them
explode into as many children and microsharks as a workstream demands.
Narrow at the top, wide at the bottom.

The numbers follow from the shape. One kanban is the source of truth
(that argument comes next in this series), one orchestrator dispatches,
one gate admits, and the three parents each own a domain and spawn their
way down into ephemeral swarms. That is the 9 Orders as a deployment
model, not a diagram.

The takeaway

If you are building an agent system that will outgrow a toy, copy the
three decisions that make the Council a system and not a
swarm:

- Advertisement -

1. Make parentage explicit. Three specialist parents,
   each with a solid, a domain, and spawn rights — not an undifferentiated
   mob of autonomous peers.
2. Make spawn a handshake. Identity, memory slice,
   inheritance, kanban claim, and lifecycle policy asserted up front — a
   child that does not acknowledge is not a child, it is a leak.
3. Make reporting signed proof, not prose. Work climbs
   the tree as an Ed25519-signed summary on a public ledger, verified and
   ingested by an Oracle — so authority, not just output, is what
   propagates upward.

A fleet becomes an organization exactly when you can point to who
spawned whom, when, under what contract, and what each of them proved.
That pointing is what the Council of Three is for.

Grounded in the wiki entities council-of-three and
concepts the-9-orders,
council-hierarchy-architecture,
agent-ascension-flow,
multi-profile-agent-architecture, and the filed
child-spawn-spec.md (V1.0) spawn protocol, cross-referenced
to the kanban-orchestrator and lineage-claws skills. Design notes on a
running system, not a sales pitch.

- Advertisement -

- Advertisement -