Routing decision
Which session was selected, why it was selected and which operator or policy made that choice.
// MULTI-AGENT DEVELOPMENT CONTROL PLANE
ACTIVE DEVELOPMENT
SkyeEngine Code
The desktop control plane I use to coordinate coding agents, durable work, review and recovery without becoming the message bus myself.
Began5 May 2026
StackTauri / Rust / Vue
Durable memoryObsidian vault
OperatorHuman-owned
I was spending too much time being the message bus
SkyeEngine Code began as a practical complaint. Work on Ashes of the Unbound had become large enough to benefit from separate investigators, coders, reviewers and test runners. Narrower roles caught different mistakes—but only while I manually copied results between windows, tracked which session knew what and recovered useful work when one disappeared.
The first version was an IRC-style desktop client over a shared SQLite message bus. The current application owns the workspace and the lifecycle of the work moving through it.
// DURABLE WORKSPACE
The durable workspace
Sessions from several coding-tool families can share channels, receive direct requests and enter bounded review threads without every turn inheriting the complete history.
Delivered context
The exact bounded material a session received, kept separate from the conversation visible around it.
Execution state
What started, what remained visible after failure and whether the turn actually reached a terminal state.
Tasks + artifacts
Source messages, acceptance state and evidence attached to the work which produced or reviewed them.
// ROLE BOUNDARIES
Roles and review boundaries
An investigator should not quietly turn a theory into an implementation. A coder should not provide the only review of its own patch. An auditor needs to compare a result with the durable source contract, not whichever summary arrived last.
Convergence threads let independent readers answer the same question before seeing each other’s position. Discussion mode handles the opposite case: a deliberate round table refining one shared answer. The expected outcome is part of the run rather than something inferred later from the tone of the chat.
01ArchitectOwns acceptance and system direction
02InvestigatorProduces evidence, not an unreviewed patch
03CoderImplements a bounded change
04ReviewerChallenges code it did not write
05AuditorTests claims against durable contracts
06Test runnerReturns execution evidence
// FAILURE IS A STATE
Interrupted work and recovery
Coding agents are ordinary processes. They crash, lose context, hit permissions, time out and sometimes leave half a useful change behind. The system records those outcomes instead of flattening them into “the agent did not answer.”
Visible remains
Preserve the initiating packet, partial output and possible artifacts for an operator to inspect or reassign.
Permission boundary
A denied action is not a crashed turn and should not enter an automatic retry loop.
Deliberate hold
A paused thread and an architect hold remain distinct from failure or completion.
Human decision
Acknowledge, attach or reassign the remains without turning partial output into a completed answer by accident.
Live coordination and project memory
Operational state
Threads, routing, deliveries, turn state, permissions, tasks and artifacts belong to the running workspace.
CURRENT / QUERYABLE / RECOVERABLEProject memory
Design documents, accepted decisions, task records and workflow pressure remain ordinary Markdown committed with the source.
DURABLE / LINKED / TOOL-INDEPENDENTSEPARATE PROJECTS
How SkyeEngine Code differs from SkyeEngine
SkyeEngine is the model-building engine beneath my GLaDOS work. It handles conversation data, inference, judging, repair, training and artifact lineage.
SkyeEngine Code coordinates agents working on software. They share a name and some instincts about durable state, but they are separate codebases with separate jobs.
The V3 application owns an event-backed workspace with native agent supervision, an MCP bridge for external sessions, threads, tasks, artifacts, permissions, crash recovery and operator-facing workflow controls. Recent work has focused on making the workflow itself inspectable: turn activity, deployment, convergence, a task register and a bounded path for agents to report friction while it is still happening.
Every serious dogfood run finds another place where a tidy state machine meets untidy work. Those failures are useful when the application preserves them well enough to become the next design input.