Corey James- 1platform system at a time, imported by its exact id
- 3kinds of result that come back into the room
A conversation is where decisions get made. A work order is where work gets done. Helix sits between the two, and the rule that shapes it is written at the top of its charter: it is a wrapper over my governance platform, AgentOS. It consumes the platform's binaries, command line and work graph, and it never modifies them. Durable work and durable knowledge go to the platform's own primitives, work orders, the work graph and the memory service. Ephemeral conversation stays in the interface layer.
Two directions
Work can start on either side. Starting in Helix, the operator creates planning-only systems, projects and work orders, each with its channels, files and grounding. When a work order is later applied through the platform's own authoring command, Helix binds the exact ids that command returns to the scopes it already had. Starting from the platform, the operator selects an existing system by its exact id. Helix imports its whole current tree of projects and work orders and from then on projects new children read-only. Links are never inferred from names or paths, and general discovery is deliberately switched off.
The boundary
Every read of the platform goes through the read-only adapter, with constant-time bearer authentication and bounded blocking reads. If a platform source goes missing, Helix shows it as missing or unavailable and deletes none of its own history.
What stays where
Context that follows the scope
Every conversation sits at a canonical scope, a system, a project, a work order, or a participant's private conversation. Channels and threads are activity streams inside a scope, never scopes themselves. Retrieval follows the level of invocation, and writes go only to the exact current scope.
There is never estate-wide retrieval by omission.
Each turn, the bridge builds an immutable envelope around a grounding packet, stamped with revision watermarks so a model can tell a current packet from one still catching up. An envelope whose revision does not match its packet is rejected.
This design is one of my filed inventions, described at explainer depth in Family Three.
The conversation becomes the work order
When a council ratifies an outcome, the operator can continue it in a mode that builds the implementation plan. The same seats author the human-readable plan and the canonical work-order document against the platform's existing authoring packet, and validate it with the platform's own render-and-validate command, which checks the package without applying it. The owner applies it later, as a separate and deliberate step. No new work-order format, tool or authoring path was created for this; the council produces what the platform already accepts. The council side is in Three councils I threw away.
Delegation without a council
Ordinary work does not need a council or a work order. A Teams user, or the voice agent on their behalf, can delegate a task to a containerised worker running a frontier model's authenticated session, locally or as an on-demand cloud job. Ownership comes from the Microsoft sign-in, hosts are outbound-only, credentials are minted per execution, and the job is observed and cancellable from the chat. The cloud path runs under the same daily budget gate as everything else, described in One call to a GPU anywhere.
What this demonstrates
I can join a conversational layer to a governance platform and hold a hard line between them: reads through one door, writes through the platform's own commands, and knowledge scoped so that a model sees exactly what its level of the tree entitles it to.
I set the wrapper doctrine, the scope model and the read-only boundary, and directed AI coding agents, a mix of frontier and open-source models, that implemented them under my governance system.