AI Infrastructure

Three coding agents work on this homelab, and one of them can change it. That makes the interesting question not which models run here but what stands between them and anything that matters.

The short answer: the agent that proposes a change is never the agent that certifies it, and nothing reaches the lab without a human approval bound to a hash of the exact plan. The longer answer is below, including the parts that don’t work yet.

Who does what, and who may change things

Different powers on purpose. Only one of these can alter the lab, and only inside a scope a human approved.

Claude Code can change things

Coordinator, planner, and the only agent permitted to change anything.

Read-only tools for every review stage; write tools only for the one mutating stage
Runs under root-managed hooks that log every tool call to a hash-chained ledger
Cannot verify its own change — the verification stage excludes it by design

Codex prepares, never deploys

Implementation and test plans, and independent review of anything Claude proposes.

Reviewed the one security-control change Claude wanted, and recommended against it
Ran the vulnerability scan that drove a full container remediation pass
Has its own rate limit, so the council has to cope with it being unavailable

Kimi Code read-only

Independent read-only auditor and long-context reviewer.

Launcher verifies a checksum manifest over its own policy files before it will start
Refuses prompt mode, session reuse and resumed approvals — so it cannot be automated
Participates through a deliberate human handshake rather than a widened guard

Moderator read-only

A fourth model that reviewed nothing, and merges what the other three found.

Runs on a free model on the local gateway, so the highest-volume step costs nothing
Different model family from every reviewer — a jury argument, not a cost dodge
Instructed never to resolve a disagreement by picking a side, only to state it

One request, start to finish

The orchestrator owns the state. Each agent is a subprocess that starts, answers and exits — nothing sits idle waiting, and a closed window never loses a run.

intake One request in. A run id, and a row per stage.
context One bounded, redacted pack — identical for every agent, so disagreement means real disagreement rather than different inputs.
round 1 All three answer blind, and their answers are committed to disk before anyone sees anyone else.
round 2 Each reviewer sees the others' findings, passed as labelled data rather than prose, and may revise or hold.
extra rounds Only if an agent asks for one. The conversation is as long as the work needs, not a fixed count.
synthesis The moderator merges into agreed points, contradictions, unsupported claims, a plan, and exclusions.
human approval The run stops. The approval is bound to a hash of this exact plan.
execute Claude only, inside the approved scope, with the intent written down before anything runs.
verify Kimi and Codex — never Claude, because Claude made the change.

What actually stops a bad change

These are deterministic — code, hashes and locks. Prompt instructions telling an agent to behave are not on this list, because an instruction is a request and this list is about enforcement.

Approval binding hash comparison The approval carries a SHA-256 of the plan. Edit the plan afterwards and the approval is void, because otherwise 'approved' can quietly come to mean something else.

Single use consumed once An approval is spent when the stage starts, and is specific to one run and one stage. No blanket approvals.

Exclusive claim atomic lock Reuses the lab's existing claim tool — an atomic mkdir mutex — so a human working by hand sees the same lock the orchestrator does.

Intent record written before acting Settled only when the outcome is known. An exception mid-change leaves it unsettled, and an unsettled intent blocks any automatic retry, because the lab may be half-changed.

Dry run default inert unless told The default walks the whole pipeline and changes nothing. Mutating is a separate, deliberate act — a flag at the terminal, or a button on the dashboard that appears only when an unconsumed approval already matches the stored plan. Neither route can approve anything; both only spend an authorisation that already exists.

Fail-closed redaction every write and transfer Secrets and internal addressing are stripped before anything is stored, displayed, or handed to another agent. A redaction failure fails the stage rather than passing the text through.

Two usage ceilings one outside my code The orchestrator caps a run, and the gateway caps it again per project key, so a bug in the first cannot defeat the second. The figure is not money: the CLI agents run on subscriptions with no per-call billing, so the ceiling bounds plan consumption expressed in Claude-equivalent dollars.

Load-time validation refuses to start A workflow that lets the wrong agent mutate, skips the human gate, or lets the mutator verify its own change is rejected before it runs, not caught halfway through.

What the plane records about itself

None of this stops a bad change — that is the list above. This is what makes a bad run legible afterwards, which is a different job and worth not confusing with the first.

Per-run attribution one session per run Every gateway call carries the run id, the agent and the role, so a council run is one tracing session rather than anonymous traffic indistinguishable from the chat UI's.

Run scoring five judgements Panel completeness, unsupported claims, deadlock, the operator's decision, and whether the moderator followed its format first time. All were already computed and then discarded; now they can be compared across runs.

Failure tracing errors, not just successes The gateway used to report only calls that worked. On a router with fallback chains the failures are the interesting part — a rate limit that triggered a fallback, a key missing a model from its scope.

Regression dataset verified ground truth Real review requests whose correct answer was confirmed afterwards by running the command, not by agreeing with a model. Each carries the trap the panel actually fell into.

Review interface history, side by side A local web dashboard behind single sign-on showing every run, and each agent's round 1 next to its round 2. The panel's value is the correction between them, which a scrolling transcript hides. It reads persisted state, records an approval, and can spend one — it holds no credential and never invokes an agent itself; a separate unreachable worker does that.

Operational overview across runs, not one run Where runs stop, how each agent replied, plan usage per run, and average time per stage. Colour on that page means severity and nothing else — it is read like a log console, so red has to be worth looking at.

Activity feed merged from three sources The event log carries only stage transitions. Agent replies and approvals live in their own tables, so a feed built from the event log alone would have shown a quiet lab on a busy day. All three are merged into one severity-coloured stream.

Approvals ledger everything that touched the lab Every approval with its scope, actions, plan hash and who recorded it, and every declared execution intent with whether it settled. An intent that never settled means a change may be half-applied, and that is visible without opening the run.

Homepage export counts only Separately from the dashboard, run counts go to a file served on an internal listener for the lab's front page. Ids, statuses and totals — never request text, replies or plans.

What this does not do

Stated plainly, because a security page that only lists strengths is marketing.

One of the three agents needs a human in the loop for every run. That is a deliberate decision after an independent review advised against automating it — not a gap waiting to be closed.
Prompt framing is not a sandbox. An agent with shell access can in principle exceed its brief; the controls above are what actually bite.
The evidence log is tamper-evident, not tamper-proof. Anyone who can write the file can rewrite the chain — it makes a silent edit detectable, not impossible.
The agents review one workflow. This is not a general-purpose assistant.
The usage ceiling watches one seat of three. Only one agent reports a figure at all, so the cap bounds that agent and infers the rest — it is a proxy for a subscription rate limit, not an account balance.
Scoring a run is not judging it. The scores record what the machine observed about its own behaviour; whether the panel was right is still a human reading the transcript.
Agents cannot address each other freely. They answer in rounds and may request a turn; there is no open conversation.
Letting the dashboard execute removed a step of deliberation. Before, mutating meant leaving the browser, opening a shell and typing a flag; now it is a button behind a confirm. That is accepted knowingly: the approval is still the deliberate act — a separate form naming a scope, an action list and exclusions, bound to a hash of the plan — and the button only spends one that already exists. The reasoning is written down as an ADR rather than left as a vibe.
The overview’s stage timings are machine time, not elapsed time. A stage that parks for a human is timed from when it resumed, and the timestamps are stored to the second, so anything faster reads as under a second rather than as instant. The page says both, because “human approval: 1 second” is otherwise a lie told by a true number.
The context pack bounds what an agent is *given*, not what it can *reach*. One spawned agent has already gone outside it to ask a question elsewhere, and the run record showed nothing. Tracked as an open incident rather than described as solved.

The full build, including the two times the design overruled me: Three agents, one approval gate →