01 – Purpose

The system is framed around real-time multi-speaker interaction.

The core problem is that ordinary voice assistants flatten conversation into a request/response exchange. A multi-speaker system needs to track who is speaking, who is being addressed, whether speech is partial or complete, and whether the assistant should interrupt, wait, revise or speak.

That makes it closely related to Omega's attention problem.

02 – Architecture

Recovered components include:

• live audio input;
• speech recognition;
• speaker identity states;
• thought assembly;
• revision engine;
• playback as a stateful object;
• local inference/chat layer;
• integration with broader local AI workstation tooling.

The interesting part is not any single component. It is the way they are treated as stateful parts of an ongoing interaction rather than one-shot function calls.

03 – Speaker Identity States

The system distinguishes speaker state instead of treating all audio as anonymous input.

That implies the assistant has to reason about:

• current speaker;
• possible speaker changes;
• overlapping or interrupted turns;
• conversational address;
• whether a response is intended for one person or the room.

This moves the work toward a conversation operating system rather than a voice command layer.

04 – Thought Assembly And Revision

The recovered notes mention thought assembly and a revision engine.

That matters because live conversation is incremental. A system may begin forming a response before the full utterance is settled, then revise as more context arrives.

In a text chat, revision mostly happens before output. In voice, timing itself becomes part of the intelligence.

05 – Playback As State

Playback is treated as a stateful object, not just "say this string."

That allows questions like:

• Is the system already speaking?
• Can this output be interrupted?
• Should speech be revised?
• Should it pause, resume or abandon a response?
• Does a new user turn outrank the current playback?

This is directly adjacent to attention and control policy.

06 – Current Status

The archive records this as a technical blueprint v0.1 with implementation status still to verify. The Lab should publish it as design archaeology unless code or demos are confirmed.

Source note: assembled from v2 section 31, "Real-Time Multi-Speaker Voice Interaction System." Implementation status should be checked before presenting it as built.

That distinction matters because Genesis represents the "agent runtime" phase of the work, while Omega represents the later move toward cognitive architecture.

01 – Identity

Genesis was conceived as a minimal, framework-agnostic, ecosystem-neutral, local-friendly runtime for agentic systems.

The short version was:

everything is a plugin.

Profiles were installable recipes or configurations rather than hardcoded personalities.

02 – Recovered Profiles

The v2 archive recovers profile details that should be preserved:

• Minimal;
• Contemplative;
• Developer;
• Startup;
• Ghostwriter;
• Household Ghost;
• Watchtower;
• Air Gap;
• Researcher;
• Dungeon Master;
• Personal Assistant;
• 3D Printing Ballarat.

These profiles show the ambition: a substrate that could become many kinds of local assistant or agent without locking the architecture to one product shape.

03 – Interoperability

Genesis was meant to coexist with the tools and frameworks already around the ecosystem:

• OpenHands;
• LangGraph;
• AutoGen;
• CrewAI;
• ComfyUI;
• Ollama;
• llama.cpp;
• Home Assistant;
• MCP;
• OpenAI-compatible APIs;
• Anthropic-style APIs.

The practical instinct was integration before reinvention.

04 – Local AI Home Assistant

A related Local AI Home Assistant project belongs beside Genesis. It included or planned:

• plugin system;
• voice;
• calendar;
• mail;
• skills marketplace;
• OpenAI-compatible API;
• MCP.

This marks the bridge from "assistant with plugins" to "persistent architecture with memory, attention and goals."

05 – Relationship To Omega

Genesis is a predecessor, not a discarded name for Omega.

The useful public arc is:

• Genesis explored a modular runtime for local agents.
• Its plugin/profile model established the value of extensibility.
• Omega keeps the modular instinct but changes the centre of gravity from task execution to cognition.

That difference should stay visible in cross-links and project descriptions.

Source note: assembled from v2 sections on Genesis, recovered profiles and the broader integration-before-reinvention philosophy.

The system is based on an AMD Ryzen AI Max+ 395 class machine with 128GB unified memory and ROCm-oriented local inference. That makes it different from a conventional desktop GPU box: it can attempt models and contexts that are awkward or impossible on smaller discrete cards, even when those cards are faster.

01 – The Workstation Stack

The v2 archive recovers a July 2026 layer of the open-source workstation stack:

• local inference and chat;
• coding agents;
• generative media;
• voice.

The point was not to install one impressive demo. It was to assemble a workstation where local models, coding tools, ComfyUI-style media workflows and voice systems could coexist.

02 – Hilbert Unofficial Suite

The Hilbert Unofficial Suite combined several layers:

• Hilbert Studio, a ComfyUI workflow platform;
• Genesis Runtime, an assistant/agent runtime;
• an AI code-build pipeline;
• ai-switch, a switcher intended to keep GPU-heavy stacks from trampling each other.

The suite's workflow layer was manifest-driven: declared inputs and outputs, model requirements, hardware requirements, tags, presets, registry discovery, schema validation, batch processing and quality-control scoring.

At one point the public registry was recorded as 12 categories and 89 workflows. Adult and community-model checkpoint categories were intentionally excluded from the public registry.

03 – ROCm As A Constraint

The ROCm focus is not incidental.

Most generative-AI tooling assumes NVIDIA/CUDA by default. Hilbert made ROCm and unified memory first-class constraints, which is exactly the kind of constraint the Lab should document: the engineering work required to make AI practical on the hardware actually available.

04 – Failures Count

The Hilbert archive includes operational failures:

• ROCm/unified-memory messages involving Qwen3 Coder Next and SVM allocation;
• sleep/resume instability after moving to Pop!_OS;
• a disk-capacity incident where Code state and the AI suite consumed enormous storage.

Those are not footnotes. They are part of the research output.

05 – Relationship To The GPU Farm

Hilbert and the older GPU farm solve different problems:

• Hilbert provides capacity through unified memory;
• discrete GPUs provide speed and throughput for narrower specialised tasks.

That distinction feeds directly into Omega's cognitive-cluster direction.

Source note: assembled from v2 sections on Hilbert, the recovered July 2026 workstation layer and the Hilbert Unofficial Suite.

This entry is a map, not a victory lap.

01 – The Lineage

The pattern begins in ordinary software work: WordPress, PHP, JavaScript, Node, React, C#/.NET, integrations, APIs, automation and UX. That work matters because it created the reflex that later shaped the AI systems: build tools that survive contact with users, file systems, queues, APIs, permissions and ugly operational state.

From there the archive moves through several layers:

• LLM integration inside existing software.
• WordPress and command-line agents with memory, task queues and history.
• Autonomous experiments in persistent worlds such as Screeps.
• AntBrain-style cognition experiments using perception, memory and LLM decision loops.
• Local assistants and plugin runtimes.
• Genesis as a more general agentic substrate.
• Omega as a shift away from assistant orchestration and toward artificial cognitive architecture.

The important point is continuity. Omega did not appear as a clean abstract idea. It emerged after enough agent systems behaved too much like tools waiting for instructions.

02 – What Changed

Earlier systems could be useful without being alive in the architectural sense. They could receive a task, call a model, use tools, write state, and return a result. But their default condition was still sleep.

The Omega question is different:

What would a system be doing when nobody is asking it anything?

That one question changes the architecture. Memory stops being a transcript dump. Attention becomes a real resource. Goals need to persist. Idle time becomes cognitive time. A model becomes a processor inside a larger system rather than the seat of the system itself.

03 – Why The Old Work Belongs Here

Screeps matters because persistent game worlds expose planning, resource constraints and long-running autonomous loops.

AntBrain matters because cognition framing existed before the Omega name.

The WordPress CLI LLM agent matters because it joins ordinary web tooling to memory, history and task queues.

Genesis matters because it tried to make agent systems modular: profiles, plugins, local-friendly execution and interoperability with other frameworks.

The hardware work matters because the later specialist-cluster idea depends on accepting heterogeneous compute as a design material rather than treating it as an inconvenience.

04 – Current Belief

The Lab should not be organised as a portfolio of isolated projects. It should be organised as an intellectual trail: predecessor, failure, correction, successor.

That means some entries are not "successful projects" in the normal sense. They are preserved because they explain why the later architecture exists.

05 – What Still Needs Verification

This entry is reconstructed from the knowledge base rather than independently verified against every repository or live URL. Existing public pages and repos should be checked for:

• AntBrain.
• Screeps agent work.
• Genesis Runtime.
• Local AI Home Assistant.
• WordPress-CLI-Agent-LLM-Model.
• Omega ACA.

The safe public claim is not that each project reached a particular outcome. The safe claim is that each belongs to the chain of experiments that led toward persistent artificial cognition.

Source note: assembled from Derek_Robertson_Lab_Knowledge_Base_v2.md, especially the project-lineage and archaeological-pass sections. Dates and implementation states remain conservative unless separately verified.