JujHub
An autonomous studio. A commander assembles a crew of specialist agents to take a goal from intent to a finished deliverable, under your approval, and tries to get better at it every run. The part I care about most is the safety model: how a system that edits its own code can be trusted not to edit away its own guardrails.
Overview
A one-line goal is not a product. Getting from one to the other is research, architecture, engineering, copy, and design, plus the judgement to know when it is good enough. JujHub is an attempt to automate the doing while keeping the judgement human. A commander, Juju, decomposes the goal and delegates to a crew of specialists, each holding to a named master's standard, and the operator approves anything that spends money or leaves the building.
It is a personal project, and the most ambitious thing I have built for myself. It runs on a zero-dependency C# harness: no NuGet packages, just the framework and JSON, so the whole engine builds and runs offline.
The studio pipeline
A goal is decomposed into a DAG of waves. The crew builds in parallel, each specialist recalling its own memory and working a tool loop. Their output is synthesized and put to a review board of critics that returns a verdict. A pass moves to delivery; a fail loops back to revise. Every outward step waits behind the operator's approval.
How it edits its own code, safely
The ambitious part is that the studio can improve its own source. The risk is obvious: a system that can rewrite its guardrails has none. So the self-editing organ runs behind a set of gates that it cannot route around.
A change is enacted in an isolated git worktree cut from a clean, committed baseline, never in the live process. It has to pass a green build and full test run, then a Constitution: a pure, path-only rulebook that protects the approval gate, the sandbox, the rulebook itself, and the fixed purpose, and holds the test project to add-only. A blast-radius cap refuses any change touching more than a dozen files. Only then does it park for human approval, which is the single path to main, and the merge applies on the next restart. Any gate failure discards the worktree and nothing leaks.
The engineering
The harness is event-sourced. Every session writes an append-only log of what happened, which is both the audit trail and the way a run resumes after a stop. Memory is a ledger the specialists recall from, with a vector index and an offline embedding fallback so nothing hard depends on a network. Tools are a small typed registry, workspace scoped. The whole tribe of roles, the crew, the review board, the mender that turns failed runs into written lessons, maps to models through a single router.
The tests are a deliberate choice: a plain console runner, not a framework, because the self-editing gate keys off its exit code with no restore and no network. Sixty-one suites, and most of them test the guardrails themselves: the Constitution, the gates, prompt safety, red teaming. The immune system has its own immune tests.
The interesting engineering here is not the autonomy. It is the set of things the autonomy is not allowed to do.
An honest read
The governance and safety machinery works and is well tested. Product delivery is where it fell short, and the system records that itself. Across its runs it produced one deliverable that passed review, one that failed it, and one left as a draft. The self-editing loop fired many times but, on this machine's history, never completed an approved merge to its own code.
The most reinforced lesson in its own log is a sharp one: the orchestrator could not reliably tell an infrastructure outage from a bad answer, because both surfaced the same way, so it spent revision rounds retrying failures that revision could not fix. That is a real, specific finding about where autonomous delivery breaks, and I would rather show it than a demo that hides it. The safety model is the part I would stand behind; the reliability of the autonomy is the part that needs the next iteration.