This is a textbook use case for a Hierarchical Multi-Agent System (MAS)
operating on a Blackboard architecture. Because you just built an
asynchronous, zero-blocking Actor Mailbox into the HAUKI engine, you already
have the exact foundational infrastructure required to run this.
You are effectively designing a recursive factory where AI agents, bots, and
human engineers participate as equal nodes in a distributed state machine.
Here is how we can architect this 4-tier collaborative pipeline.
The 4-Tier Collaborative Hierarchy
Each level acts as a distinct state machine that processes inputs, reaches a
consensus via a roundtable, and emits structured output downward (or reports
blockers upward).
 * Level 1: The Ideation Layer (The Oracles): This level consumes raw text,
lore, or mechanical concepts. The output is a structured JSON/YAML design
document outlining the intent of a room, simulation rule, or mechatronic
interaction.
 * Level 2: The Architect Layer (The Planners): Consumes the design doc and
translates it into strict system architecture. This translates conceptual
rules into your AST-MD intermediate representation or system topologies.
 * Level 3: The Orchestrator Layer (Project Management): Consumes the
architecture and shatters it into a dependency graph of executable tasks
(e.g., "Build mapping initialization," "Write sys_net_broadcast efun").
 * Level 4: The Execution Layer (The Builders & Testers): Consumes individual
tasks. Synthesizer bots generate the LPC code, compile it to bytecode, clone
the object, and run isolated unit tests via the REST API before marking the
ticket complete.
The Roundtable Protocol
To prevent AI hallucination loops or race conditions, each "tick" of a project
requires a structured consensus protocol rather than a free-for-all chat.
 * The Chair (Orchestrator): A designated daemon object initiates a round. It
holds the current state block and broadcasts a "Call for Input" to subscribed
participants.
 * Token Passing: The Chair passes a virtual speaking token sequentially. If
an AI agent has the token, it streams its LLM output. If Kalle, Janne, or
Petteri hold the token, the system yields and waits for their CLI/REST input,
seamlessly treating human keystrokes exactly like an asynchronous bot
response.
 * Synthesis & Validation: Once all participants have spoken, a specialized
Synthesizer agent attempts to merge the inputs into the next version of the
state block. If tests or logical validations fail, the Chair initiates a new
round with the error logs as the prompt.
 * State Promotion: When a round achieves consensus (e.g., all tests pass, or
humans vote 'approve'), the Chair locks the state and pushes the finalized
payload down to the next level's queue.
Implementing within HAUKI
You can build this entirely natively using your existing engine.
You would spawn a chair_daemon.c for each project. It runs the exact while(1)
eternal sleep loop we just tested, waking up only when a participant (human
via REST, or an external Python LLM script) posts a message to its mailbox.
Because you route everything through the Mesh IPC, a human could be chatting
from a web UI in Helsinki while an AI agent computes responses on a dedicated
Linux node, all syncing to the same virtual room inside the engine.
If we build this roundtable protocol, where should the canonical "truth" of
these ideas and tickets be storedas persistent nested mappings in a HAUKI
daemon's memory, or pushed out to an external lock-free database?